Qt thread server - problém s čekáním – C / C++ – Fórum – Programujte.com

Zdravím, chtěl bych udělat server (se spojením TCP), který bude připojené clienty obsluhovat každého zvlášť v threadu. Mám třídu Server (dědí QTcpServer) a jeho reimplementovanou funkci incomingConnection(), kde vytvořím nový thread: 

Thread *thread = new Thread(this, socketDescriptor);
    connect(thread, SIGNAL(finished()), thread, SLOT(deleteLater()));
    thread->start();

    connect(thread, SIGNAL(acceptedRequest(QString)), this, SLOT(acceptedRequest(QString)));

poté:

void Thread::run() {

    // pokud nepujde novemu socketu nastavit predavany descriptor
    tcpSocket = new QTcpSocket();
    if(!tcpSocket->setSocketDescriptor(socketDescriptor)) {
        emit error(tcpSocket->error());
        return;
    }

    connect(tcpSocket, SIGNAL(readyRead()), this, SLOT(receivingRequest()));

    //emituji signal o odeslani pozadavku na login
    emit acceptedRequest("NEW");

    exec();

}

  Po prvním připojením proběhne vše v pořádku. Clientovi je odeslán požadavek na login. Jenže odpověď která přijde už není serverem zpracována. Thread je už "mrtví" a na nic nereaguje.

Nevím jak mám zajistit, aby byl thread spuštění a čekal na další příchozí požadavek.

Díky za každý tip

a proč vůbec chceš pro každýho klienta thread? Prvně si řekni, kolik plánuješ max připojených klientů... pokud do 100, tak není důvod řešit vlákna.. kdyžtak tam hodit ThreadPool a ať se stará

Já chci navázané spojení udržet a komunikovat v něm třeba 2 minuty nepřetržitě (tzn. otázka - odpověď) pak třeba 5minut čekat a zase komunikace. To nevím jestli by to bez těch threadu šlo. Tam je podle mě možno vytvořit více socketů, ale nevím jak bych se v nich vyznal. 

Thready chci použít i kvůli tomu, že jeden client může mít i dvě paralelní komunikace a to bych chtěl řešit novým připojením od clienta a tudíš novým threadem na straně serveru.

Ten ThreadPool je zajímavý, ten mě nenapadnul. Ale pořádně nevím jak to naimplementovat a zda to vůbec nějako takto jde...

TCP si narozdíl od UDP drží spojení dokud ho nějaká strana ručně neukončí a pokud to řešíš asynchroně, tak pro komunikaci opravdu není nutný používat vlakna a kór pro kaýdej soket, kdyby bylo třeba 200 klientu, tak 200 vláken je celkem znát už, ty taky něco žerou

Tcp komunikace se řeší asynchroně a používáš pouze určitej počet vláken,(třeba 15) a ty se starají o všechny klienty a to jich může být třeba 1000

Ale většinou si 1 vlákno vystačí kolem 100-200 klientů, dneska máš celkem výkoný CPU, takže klidně i víc (pokud jde pouze o čistou komunikaci)

#4 ingiraxo
Aha díky za radu.

Ale abych ti osvětlil můj problém. Mám server který slouží jako repozit a zároveň se na něj mohou spouštět simulace. Clienta, který se připojí na server pomocí jména a hesla. Může si ze serveru natáhnout nějaký soubory (jedna funkcionalita) a nebo požádat o simulaci (druhá). Ta trvá např. dvě minuty (každou sekundu se něco pošle). Bohužel si těch simulací může spustit více.

Takže asi pokud by to šlo, clienty bych řešil normálně. Předat do funkce pro obsluhu socketDescriptor? A pokud by byl požadavek na simulaci, tak až poté vytvořit thread se simulací (předal bych asi také socketDescriptor).

Nebo jsem dostal tip, abych na clientovi (při druhé+ simulaci) začal novou instanci clienta - připojit se znovu na server. Ale simulaci bych asi musel řešit také v novém vlákně.

Descriptor by si musel předat tak, či tak, to je handle, kterej slouží ke spojení soketu se serverem... ono je fakt důležidý vědět, kolik plánuješ max. připojení... pokud to je do 100, tak můžeš pro každej klient jedno vlákno, pokud víc, tak orčitej počet a ať se o klienty staraj (vlákno který nemá co na práci, tak se ujme požadavku klienta, jinak klient čeká ve frontě dokud se neuvolní nějaký vlákno)

ale pokud možno, tak všechno řeš asynchroně a vlákno pouze tam, kde by to mohlo zatížit hlavní vlákno

a hlavne pocitat s velikosti zabrane pameti pro jedno vlakno... 200vlaken s defaultnimi cca 10MB na linuxu/vlakno znamena ze to chce mit 2GB ram (a na 32bitovem systemu uz se clovek nemuze dostat nad 4GB RAM - tedy teoreticky, prakticky je to o hodne mene)

mě jde např. jenom o pět současně...

#6 ingiraxo pokud bych to řešil bez vláken (u simulace), tak si závolám funkci třeba emitováním signálu. Spustí se simulace, začne odesílání dat clientu. Ale když v tom přijde další požadavek na simulaci, tak já budu muset čekat až se mi vykoná předešlá. Já bych právě chtěl, aby šli obě (více) současně. Tady asi bude hlavní vlákno nevytížené, to bude čekat na dlaší požadavky které mu přijdou. Popřípadě mu budou předávány výstupní data z vláken aby je posílal.

a jak to myslíš asynchronně, jsem myslel že když vytvořím vlákno, tak se v něm vše dělá samo bez ohledu na ostatní vlákna. Nebo tam je nějaká synchronizace?

stručně řečeno asychnonizace znamená, že připojení bude ne-blokový, tzn. že pokud např. client A bude chtít něco po serveru, tak server mu to pošle a nečeká na odpověd klienta A ale jde si pokračovat dál ve svoji práci - může třeba poslat další věcí opět do network streamu

Tudiž vlákno použít pouze tam, kde je vytížení (např. server musí vytvořít archiv ze souboru a ten odeslat)

Ešte by si to mohol riešiť takým spôsobom, že jedno vlákno len prijíma správy od všetkých klientov, správy ukladá do fronty a iné vlákna sa už budú starať o ich spracovanie tak, že si vyberú správu z fronty a spracujú. Potom tam budeš asi ešte potrebovať jedno vlákno na odosielanie plus k nemu fronta správ na odosielanie.

Je to pekná implementácia servera a naviac si môžeš doimplementovať prioritu správ, takže sa niektoré správy budú spracovávať prednostne.

děkuji všem, využil jsem vaše poznatky a zdárně se to blíží ke konci :-)

A otázečka: Nevíte jak bych přiměl, aby Thread počkal na nějaký signál a pak zase pokračoval v práci. Kdyby mu šla udělat na chvilku pauza