Dotaz: Komunikace Server/Client knihovna v C++

[Šangala]

Ahoj, potřebuji spíše obecnou inspiraci či tip, mám „nápad“ na aplikaci a již jsem si to i odzkoušel hloupějšími nástroji na to jak bych si to představoval (PHP, MySQL, Apache) a chtěl bych to v C++.
Aplikace Server - Client a dotaz směřuje hlavně na serverovou část.
Jednalo by se čistě centrální řízení, server vše říká co chce od clienta, kontroluje to co mu dal, odmítá se s ním bavit (překročení definovaných limitů, priorit, nesprávné chováni klienta apod.).
Komunikaci sice iniciuje klient, ale server rozhodne, kdy a o čem se s ním bude bavit.
Každá komunikace (jednotlivý přenos) je vzájemně podepsaná (i client ví, že se baví právě ze serverem a, že data jsou od něj - 2× klíče/priv. a pub./ )
Komunikace může být velmi aktivní (spousta malých objemů s velkým množstvím kroků tam a zpět), ale také se budou přenášet velká data, ale client nebo server bude zodpovědný za dělení a postupné odesílání po definovaných blocích (řádově 1MiB až desítky MiB) a server rozhodne kolik takových „částí“ přijme za časovou jednotku.
No a nechci řešit tu vlastní komunikace, v zásadě mi vyhovuje webserver (i když ta serializace dat ze serveru ke klientu je naprd), protože to obvykle projde všude a můžu to pustit zabezpečeně zadarmo (https) a taky, protože tam bude i web aplikace jako „monitoring“ a může být někdy výkonnostně náročnější, než se obvykle očekává od web aplikace, takže mít kritické věci (nebo celé) v C++ by nebylo od věci.
Napadlo mě nechat si myšlenku web serveru a použít například něco jako WT a použít vestavěný, ale nemám s tím žádnou zkušenost.
Ale taky tam bude spousta zbytečné režie při čilé komunikaci, lepší by bylo udržovat komunikaci aktivní, ale nevím co použít „něco“ abych toho musel řešit co nejméně. Mělo by to být klasika, číhám (server) když někdo chce komunikovat „otevřu mu cestu“ a spustím pro něj instanci (multi-threading). A ať to zařídí i serializaci a přenos dat, pošlu strukturu/dostanu strukturu (že se to postará o i(e)ndiány je samozřejmost). Musí to být GPL (nebo kompatibilní), musí to být limitovatelné na počet spojení a mělo by to (číhač) ty spojení mít pod dohledem a moci s nimi komunikovat. Bezva by bylo kdyby to už rovnou i komunikaci šifrovalo a podepisoval (ale není to podmínkou).
Nějaká knihovna a zkušenosti s ní, nebo „¿kudy?“ - dík.

---

---

Odpovědi

[NN]

Nechcete vyuzit standartni socketove API?

http://www.root.cz/serialy/sokety-a-cc/

NN

[Šangala]

No popravdě, ne. Je to samozřejmě možnost, ale chtěl bych se raději soustředit na to ostatní. Ona ta přenášena data jsou v zásadě velmi jednoduchá, když jsem to testoval, tak jsem si vystačil jen se třemi typy struktur (a dokážu si představit rozšíření na 6).
Takže bych raději něco jako:
Vytvořit instanci „něčeho“ Server, zdědit nějaký „interface“ k těm strukturám a zdědit nějaký „interface“ nějakého „instance_thread“ doplnit metodu „run“, něco tom zaregistrovat a hotovo. (Pak samozřejmě další krok, nějaká komunikace s jednotlivými „instance_thread“, třeba nějaký Monitor přiřazený Server.)

[chsajarsa]

Co treba xmlrpc-c? Nasazeni je opravdu velice trivialni a velice dobre funguje.

[Šangala]

Díky to by mohla být, jak doufám, že přibude nějaký další tip, jedna z možností.

[Ladicek]

Možná hledáš něco jako MsgPack/Avro/Thrift/Protobuf? (Protocol Buffers tedy nemají vlastní RPC, ostatní myslím ano.)

[Šangala]

Ohó, díky, zběžně jsem to prošel a otázka, proč jsi dal MsgPack jako první?

[Ladicek]

Protože mi je nejsympatičtější Nepracoval jsem ani s jedním, ale Protocol Buffers nemá vlastní RPC (i když existují nezávislé implementace) a Avro je na tom, pokud vím, ne úplně dobře s dokumentací.

Určitě existují i další binární serializační formáty s vlastním RPC, od chvíle, co se objevily Protocol Buffers od Googlu a pak Thrift od Facebooku, tak se vyrojily jak houby po dešti.

Případně by tě možná ještě mohlo zajímat ZeroMQ, ale to už je o trochu něčem jiném.

[Šangala]

Taky mi 'MsgPack' tak na první pohled přišel.

[foldy]

Jo webtoolkit je super, vřele doporučuju. Mají jak vlastní webtoolkit server tak stačí i fastcgi do apache. Musíš trocha vědět jak to rozchodit a je s tím dost práce ale jinak super.

[Sten]

C++? Boost.ASIO. Umí to i šifrování.

[Šangala]

Vždycky jsme se vyhýbal tomu co začínalo boost, ale třeba je čas to změnit, šifrování (bez práce) je velmi lákavé (a toto se mi i v příkladech líbilo).
Ukázkové kódu se mi tedy moc nelíbí, ale v tomto případě budu muset na to více juknout, třeba se to jen díky širokosti záběru tak tváří a bude to možné snadno hezky něčím jednoduchým obalit na potřebnou funkcionalitu.

[Sten]

Ukázkové kódy vypadají tak, jak vypadají, protože Boost se snaží být stejně pružný jako STL (a možná proto se mu spousta lidí zbytečně vyhýbá). Vy to zřejmě stejně zabalíte do nějakých objektů, které si jenom poskládají to, co potřebují.

[Šangala]

S tím asi nedá nic než souhlasit, zkusím se s tím popasovat a pravděpodobně zvolím tuto cestu. Dík.

[__dark__]

Ještě se mrkni na Node.JS, pokud se nebojíš javascriptu (a pokud jsem pochopil co chceš dělat). Node lze celkem pěkně kombinovat s C++, takže rychlostně by to mohlo být v pohodě.

[Šangala]

Javascriptu se nebojím, ale je mi odporný. S Node.JS jsem se již setkal, nemyslím, že je to dobrý kandidát. Ale stejně díky.

[Saljack]

Ja ted pisu aplikaci, kterou bude moc obsluhovat pres jeji REST rozhrani. A jelikoz je to desktopova aplikace, tak i serverovou cast pisu v Qt. Navic Qt ma jiz SSL sockety, kterym staci strcit certifikat a privatni klic a ostatni ten socket provede sam.

[Šangala]

Díky Ti, Qt nechci.