Jak na komunikaci přes Tcp (C++ Qt) – C / C++ – Fórum – Programujte.com

Zdravim,
chtěl bych se zeptat hlavně těch, kteří někdy dělali app server/client v C++ (Qt). Dělám právě jednu app, která by měla fungovat hlavně jako chat (něco jako IRC), kde bude hlavní chat a potomo možnost komunikace jen mezi klienty.
Aplikaci řešim asynchroně, ale nejak mám problém s odesíláním paketů. Řekněme, že se klient připojí k serveru, tak jak by měl vypadat takovej paket?

To bude muset asi obsahovat všechny připojený uživatele (seznam jejich jmen a id), aby se zobrazilo kdo je online a potom veškerý informace o uživateli?
Co když uživatel nastaví, že bude ve statusu třeba "Away", tak jakej by měl mít formát ten paket? Nějaký ID klienta a číslo (enum) jeho statusu a server to odeslat všem (opět jak by měl vypadat paket).

Nemám ani takovej problém to naprogramovat, ale spíš se zasekávám na týhle logice/principu, na kterým to má fungovat, aby to bylo rychlý a bezpečný
Jinam mám vlastní knihovnu, kde jsou třídy pro server i klient a app jí využívaj.

Dík

Internet Relay Chat Protocol

#2 zlz
tohle víceméně vim, ale nějak nechápu, jak bych měl formulovat paket... dneska mě akorát napadl tento způsob: 

enum PacketFlag
{
    Neco1,
    Neco2
};

struct Packet
{
    int hSender;
    int hReceiver;
    PacketFlag flag;
    QByteArray data;
};

A toto bych vlastně (celej objekt struktůry) serializoval na byte pole a to odeslal... vždy, při jakémkoli přenosu informací mezi klienty nebo ze serveru na klienta by se odeslala tato struktůra..

Potom by se to jen vždy deserializovalo a bez porblému bych měl přístup k datům.. něco jako: 

void prichoziData()
{
    Packet *packet = Packet::Deserialize(socket->readAll());

    switch (packet->flag)
    {
    case Neco1: ... break;
    case Neco2: ... break;
    }
}

Takže by mě teď zajímalo, co si o tom myslíte, zda toto řešení by bylo dobré nebo ne :)

Ovšem jediná asi nevýhoda co mě napadá je, že datovej přenos bude o něco větší, páč serializace objektu zabere až 10x víc (tipuju) a abych to řešil tak, že bych každej parametr hodil do pole a oddělovat nějakým znakem a poslal je blbost podle mě...

PS: Pokud třeba ve struktůře (hReceiver) bude 0, tak zpráva bude určena pouze serveru (je to descriptor)

protokoly sou ruzny... IRC protokol pouziva pro jednotlive zpravy jednu radku... kde jsou vsechny informace co jsou potreba... od koho, kam, co... jednotlivy veci oddelene mezerama a oddelovac zprav je pak odradkovani...

ale pokud se ti takove reseni nelibi muzes vyuzit neco jineho... diameter, xml, textovy format (treba jen jiny tvar nez IRC), tag-lengt-value (TLV - hodi se i na binarni data), ..................... vycet je obrovskej

jo a jen pro upresneni - socket se chova jako obycejny vstupne vystupni stream (co tam zapises, mel bys dostat na druhe strane) ale hodi se to i sem tam kontrolovat

#4 KIIV
Jo dík, celkem ten diameter mě zaujal a můžu se spíš zeptat na názor na to, co jsem předtim napsal? To řešení paketu, kterej by se vždy odeslal, protože si myslim, že tento způsob by měl být bezpečný a i celkem jednoduchý, jen nevim jak se na to bude tvářit CPU, když bude muset každej paket serializovat a deserializovat a odesílat tak trochu větší množství dat.

Vim, že socket je podstate síťovej stream co odesílá nějaky byte pole a tady právě by mělo fungovat i odesílání souborů.. např. kdyby flag byl "file", tak vim, že celý byte pole je podstate soubor (jen bych někde musel ochovat co to je za typ).

A jak si psal o tom IRC, tak toto byla první věc co mě napadla, ale tento způsob se mi moc nelíbí, to bych na serveru musel parsovat vždy celou zprávu (kdyby to bylo oddělený mezerama) a to ještě zpráva by musela bejt v base64, páč kdyby obsahovala mezery, tak by to parsovalo i zpravu samotnou.. to potom zpracovat a opet celý spárovat a odeslat... tohle mi přijde trochu komplikovanejší no

PS: Snažim se vytvořit nějakej vlastní protokol na Tcp, právě :-)

no ono parsovat to musis tak jak tak... jinak diameter je zrovna jeden z tech hnusnejch protokolu :D to nakonfigurovat aby fungovalo .. to je na pul dne kdyz to clovek nema v oku

z hlediska zkusenosti jsou nejhorsi protokoly s urcitou pevnou strukturou dat - obzvlaste pokud musis pocitat i s ruznejma procesorama... (ostatne vetsinou se pres sit pouzivaji protokoly co prevadeji cisla na big endian)

treba takovy tlv muzes hodit ruzny tagy pro ruzny eventy a uvnitr pak jednotlivy tlv pro dejme tomu odesilatele, jeho adresu, priemce a data...

No to právě bych nemusel parsovat, kdybych serializoval objekt s hlavičkou, převedu objekt na byte a opět pak složim do objektu a už se jen odkazuju na proměný v objektu
 

To TVL co si psal, je už nějakej hotovej protokol, já bych chtěl spíš vlastní udělat, proto se ptám na názor na řešení, který jsem tady uvedl :-) Jen nemám s tím moc zkušeností, tak se ptám, zda by se to takto mohlo řešit nebo spíš zda je dobrý odesílat přes stream serializovanej objekt

princip je stejnej jen ruzny zapisy... poznat typ(tag) vedet jak jsou dlouhe data, a ty data... v typu muze byt jeste zakodovano napriklad ze to je slozenej tag (tj ze obsahuje uvnitr dalsi TLV...)

nic jinyho vesmes nevymyslis :D muzes k tomu rozsirit jeste datovy typ - takze TTLV - tag, type, length, value...

nebo v horsim pripade pevne dannou strukturu - ale jakmile zmenis tak musis zmenit vsechno

No dobře, ale pevná struktůra by musela bejt skoro vždy ne?
Řekněme, že bych odesílal (odUzivatele, kUzivateli, flag, text), tak se přece odešle vždy stejný parametry (hlavičku), jen jiný hodnoty ne?

krom toho ze na ruznejch platformach to bude vypadat jinak, existuje taky zarovnavani struktur.. opet na kazdy platforme jinak, jiny byte order u cisel... jiny velikosti typu pro ruzny platformy...

nemluve o velikostech retezcu... kdyz tam das   char data[2048] musis je poslat cely... resp nemusis ale taky nesmis za tim nic uz mit jinak stejne zase budes muset zpracovavat, posouvat kusy pameti a tak...

No vidim to tak, že to udělám jak jsem psal, páč struktůra je sice pevná, resp. počet parametrů, ale velikost je dynamická, takže nemusim řešit na straně klienta/serveru jak velkej mi přijde paket, abych ho mohl nacpat do bufferu a bát se tak, aby to nepřeteklo