Server se dize i salje BROADCAST ili MULTICAST paket.

Klijenti je prime, svaki sebi odredi random timeout, npr od 1 do 5 sekundi i nakon timeout-a pokusava da se poveze. Na ovaj nacin nemas preopterecenje u vidu hiljadu istovremenih zahteva.

Zatim jos npr 2 puta ponovis BROADCAST ili MULTICAST paket, da bi se eventualno nepovezani povezali.

Asinhrono pratis promene na socket-ima. Gde se veza prekine, tu se povezes ponovo. Povremeno ponavljas ove BROADCAST ili MULTICAST pakete, da bi se novopridosle masine povezale.

Posto su ti paketi mali, mozda mozes da radis i sa UDP protokolom.

Naravno, da bi ti broadcast radio, moras biti na privatnoj mrezi. Ako pises program za internet, ne mozes koristiti BROADCAST ili MULTICAST.

Hmmmm, radio sam slicne stvari ali na unixu... A na Win platformi malo mi je i nelogicno raditi takav vid servera, pogotovo sto je velika sansa da padne prilikom "bombardovanja" portova sa toliko klijentskih masina...

Zaboravi MFC klase. Za tako nešto moraš da koristiš IO Completion ports i AcceptEx. Googlaj malo, ili ako te ne mrzi pogledaj kako je to odrađeno u Apache 2.0 za Windows.

E, da! Možda ne bi bila loša ideja da pogledaš ACE:

http://www.cs.wustl.edu/~schmidt/ACE.html

Izgleda da je IO Completion ports jedino prihvatljivo resenje s obzirom da je to preporuka koju sam dobio na 90% foruma na kojima sam postavljao ovo pitanje, i nasih i stranih. Bilo koji drugi alat s obzirom na zahteve aplikacije izgleda ne pije vodu. Hvala na preporukama!

Iz licnog iskustva definitivno i jedino Async. I/O with completion port.

Čisto da ne bude zabune, async socket su nešto drugo (šalju WM poruke). Ovo o čemu pričamo je overlapped IO i completion port.

Ja sam to nekako ovako ukapirao: U slucaju IO completion porta vrsi se provera da li postoji nesto u njegovom redu za cekanje ali se provera vrsi neprekidno i slobodni thread-ovi obradjuju pakete. Jedino u slucaju da je zauzet citav thread pool thread koji je poslednji prihvatio zahtev prihvata i sledece pakete.