Multiplatform kliens-szerver architektúra
2009-12-29T23:52:21+01:00
2009-12-31T10:34:58+01:00
2022-07-02T12:25:24+02:00
  • C++ os socket kezelésnek csak annyi az előnye hogy te is jobban átlátod hogy mi miért és jobban tudod a későbbiekben optimizálni ha szükség van rá. Pl. ha egyidejüleg 30000 kliens csatlakozik és nyomja az adatokat akkor szerintem érdemes socketekkel bajlódni. Ha nem ennyire kritikus, akkor meg használhatsz bármi egyszerübbet amit könnyen tudsz használni.

    Pl. nemtudom hogy hányan vannak tisztában azzal hogy a WPF hogy müködik a háttérben (mikor/hány thread, thread polling van e?, select vagy IOCP?, stb)
    Mutasd a teljes hozzászólást!
  • Köszönöm szépen mindenkinek a gyors reagálást és a segítő véleményeket! Úgy gondolom, hogy az elhangzottak alapján a Mono+WCF a toronymagas esélyes most nálam.

    Bubba: egy kicsit valóban félreérthetően fogalmaztam. Természetesen nem egy adott feladat megvalósításának bonyolultságától függ a projekt. Tulajdonképpen arra voltam kíváncsi, hogy vajon a C++-ban történő implementáció a tapasztalataitok szerint van-e annyival jobb (ha jobb egyáltalán) a többi alternatívánál, hogy megérje a "rögösebb" utat járni. A többség hozzászólása azonban azt támasztja alá meglátásom szerint, hogy a válasz egyértelműen 'nem', sőt többen óva intenek a C++-os megoldástól.
    Mutasd a teljes hozzászólást!
  • De messze a legegyszerűbb a WPF-WCF kombó, szerver oldalra meg vagy windows + WCF vagy mono + WCF, bár ott azért nem árt figyelni mert még nincs minden kész.
    Mutasd a teljes hozzászólást!
  • A multiplatform dolgot nem értem teljesen.Mi ezzel a célod amúgy?
    Ha a license a drága a sok(?) kliens gépre, akkor web-es UI osztjóvan' a platfromfüggetlenség.

    A szerver oldali multiplatform az kompromisszumos és 1általán nem biztos h megéri. Szerver oldalra vagy Java-t vagy Windows alapokon rendes .NET et raknék (MSSQL-lel a kell), és persze WCF-fel.
    A WCF-fel ki tudsz egyébként könnyedén szolgálni szinte bármilyen nem MS klienseket is, Java-tól kezdve mindenféle nagygépes LOB cuccig. Szal ez tűnik a legrugalmasabbnak.

    TCP:
    gondod lehet a NAT traversal-lal. Nem biztos, hogy a kliens infrastruktúra 'beállitása' megoldható vagy triviális és nemcsak a tűzfalak miatt.Néha nem juthatsz át oda-vissza bizonyos TCP-n, pl. rendes céges hálón, vagy különc ISP esetében.
    Viszont ha WCF-et használsz a szerver oldalon, akkor azt is 1szerü, hogy a tucatklienseket TCP-n, a speckó klienseket meg HTTP-s bindinggel szolgálsz ki egy időben. Ez gyerekjáték a WCFfel.

    Ha nem WCFet használsz, akkor a kommunikációs réteged korlátozni fog, nem lesz 1szerü csak úgy hipp-hopp transportot váltani,TCP->HTTP(s),reliable messaging-et, tranzakciókezelés, aszinkron kommunikáció, streaming vagy disconnected (vagy gyakran occasionally connected) klienseket kezelni. Csak úgy ha már jóelőre biztosan tudod évek multán is elég lesz neked a TCP socket :)

    amugy valóban nem a TCP socket programozás a kihivás, hanem a message framing és maga a protokol, illetve a TCP-re épülő stack rész. Gondolj bele, hogy gyakran fog (az elején főleg) változni az adat amit át kell küldjék és vagy rugalmas és lassú sorositót csinálsz, vagy kézzel utánna kell húznod mindig a vátozást. WCF-esetén ez a dobozba van.

    Az is út lehet, ha ragaszkodsz a WPF-hez, h a kliens oldali WCF-rétegeddel Java-s webservice-ekkel beszélgetsz.Azon múlik, hogy melyik technológiát ismered jobban.
    Mutasd a teljes hozzászólást!
  • A WCF es JAX-WS emlitese miatt feltetelezem, hogy a kliens-szerver kommunikaciot legszivesen SOAP-al oldanad meg.

    2. C++ + TCP - vethetsz egy pillantast gSoap-ra vagy Apache Axis-re, nem kell foltetlenul sima TCP-vel szivni, de az teny, hogy a nyelv miatt nehezebb, tobb a hibalehetoseg, stb. Cserebe viszont a szerver miatt nem kell mono/JRE-t telepiteni.

    4. JAX-WS (GlassFish): Szerencsere ehhez nem kell foltetlenul egy GlassFish-meretu alkalmazasszerver, metro+jetty is megteszi, vagy ha nem ragaszkodsz JAX-WS-hez, axis+jetty!
    Mutasd a teljes hozzászólást!
  • Ha pedig a túloldalon wpf akkor ez leginkább a mono/wcf lesz.
    Mutasd a teljes hozzászólást!
  • De az olyan is lesz...


    Aki először csinálja, lehet hogy 2 óra és nem 20 perc.
    De akkor sem ettől kéne függjön a platform kiválasztása.

    Szerintem azt kéne használnia amihez legjobban ért a kérdező. Ha semmihez nemért akkor meg azt amit megszeretne tanulni.


    A códot pedig vagy kódnak, vagy code-nak kéne írni


    Ünnepek között, másnaposan is?
    Mutasd a teljes hozzászólást!
  • De az olyan is lesz...
    A códot pedig vagy kódnak, vagy code-nak kéne írni :)
    Mutasd a teljes hozzászólást!
  • Amiket felsoroltál, nem lehetnek valós érvek.

    "a socket programozása valamivel bonyolultabb"

    ...nehogy már egy socket programozás bonyolultságán múljon a projekt.


    --Hiena-- :
    Java TCP szerver: 20 perc meló (copy paste cód)
    C++ socket: 30 perc meló (copy paste cód)
    a többinél meg kevesebb

    persze ez csak az alap ...aztán hogy milyen adatok mennek ezeken a socketeken, az már alkalmazásfüggő.

    Szóval véleményem szerint hamarabb lehet irni egy c++ tcp szervert mint egy új témát nyitni a prog.hu -n

    Mutasd a teljes hozzászólást!
  • Szerintem ez lesz az amit keresel. 10 részből áll (most) és szerintem elég jó. Ha nem mono akkor én még javával próbálkoznék. C++-szal én is csak végső esetben.
    Mutasd a teljes hozzászólást!
  • A Java + TCP megoldáshoz szólnék.
    Winows, LINUX, Mac kipipálva.
    Serviceként futtatás ok.
    Jól skálázható socket frameworkok vannak hozzá és kommunikációs protokollt sem kell fejlesztened, ha nincsenek túl egyedi igényeid. Bevált, beágyazott webszervereket, sőt adatbázismotort is találsz. Ráadásul nincsenek extra licencdíjak.
    Rugalmas, jól automatizálható telepítőket tudsz összeállítani.
    Homogén, 100% java.

    ui: ezt az alkalmazást szerintem ne C++ ban akard megírni. Hacsak nincsenek ferde hajlamaid. :)
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Egy kliens-szerver architektúra szerint készülő szoftver előkészítésén dolgozom. A klienst minden valószínűség szerint WPF-ben fogom fejleszteni, így az (egyelőre) csak Windows-on fog futni. A szerver feladata tulajdonképpen adatbázis tranzakciók végrehajtása (+ login, logout természetesen), amelyekre a kliensek kérik fel. Alapvetően azt szeretném elérni, hogy a szerverem működjön Windows, Linux (esetleg Mac) környezetben. Fontos még ezenkívül, hogy előfordulhatnak olyan esetek, hogy a klienst és a szervert "standalone" alkalmazásként egyetlen gépre kell telepíteni, ezért fontos szempont, hogy a telepítés a lehető legnagyobb mértékben automatizálható legyen.

    A fő dilemmám a szerver és a kliens közötti kommunikáció megvalósításának módja. Eddig az alábbi forgatókönyvek jutottak eszembe:

    1. Java + TCP: Ami tetszett, hogy egyszerű és átlátható a Java absztrakciós rétege. Ami számomra egy kicsit aggasztó (nem tudom, hogy jogos-e), hogy a szervert szeretném service (daemon)-ként futtatni, ami jar fájlok esetében nehézkes. Ezenkívül még a TCP-vel alapvető probléma, hogy a kommunikációs protokollt is külön ki kell fejleszteni, ami jelentős többlet erőforrás-igény.

    2. C++ + TCP: Itt nagyjából az 1. verzió előnyeinek és hátrányainak a negáltját tudnám felsorolni - a socket programozása valamivel bonyolultabb (bár ez sem a járhatatlan kategória), azonban a kész szoftver nem igényel külön futtatókörnyezetet, és a service/daemon-ként történő futtatás sem lehet probléma.

    3. Mono/.NET + WCF: Egyelőre ez a kombó csábít a legjobban :) Itt igazából az a legfőbb bajom, hogy nulla tapasztalattal rendelkezek azzal kapcsolatban, hogy a Mono hogy kezeli a gyakorlatban a WCF-et, illetve itt is felmerül a kérdés, hogy mennyire bonyolult Linux alatt egy Mono alkalmazást daemon-ként futtatni (bár a fórumokat elnézve úgy tűnik, hogy ezzel nem szokott probléma lenni).

    4. JAX-WS (GlassFish): Bár a Web Service felel meg talán a leginkább az igényeimnek, azonban ettől azért tartózkodom mégis, mert nem szívesen követelem meg a felhasználótól, hogy a Java futtatókörnyezet mellett még rendelkezzen egy GlassFish (JBoss, WebLogic...) alkalmazás szerverrel.

    Igazából az érdekelne, hogy Ti melyik utat választanátok? Érdekelnének érvek, ellenérvek egyaránt.

    Előre is köszönöm a hozzászólásokat!
    Mutasd a teljes hozzászólást!
abcd