winsock ?

lytter med..

Tja, kan kun sige hvad der står her, UDP har ikke garatenret levering:

http://www.gamedev.net/reference/articles/article711.asp

Så hvis der skulle vøre noget connectionless i directplay, vil jeg tro det enten ikke er gennem tcp/ip protocolen eller noget de "faker" ved at "emulere" det på en eller anden måde.

Unlike TCP, UDP does not implement "quality assurance" with regard to the data that it transmits, in any way, shape, or form. UDP packets may be duplicated, out of order, or not received at all. On the other hand, UDP does cut back on the mammoth TCP header overhead, which adds up over time, especially if your TCP packets are so large and ill-designed as to consistently be split up.

Hverken TCP eller UDP kan garantere levering. Modtageren kan jo have trukket stikket ud og så kan du sende nok så meget TCP, pakken vil ikke blive modtaget. Forskellen mellem connection-oriented (TCP) og connectionless (UDP) protokoller er at en connection-oriented protokol forventer en kvittering af en eller anden form fra modtager, som sikring for at pakken er modtaget. Dette gør connectionless protokoller ikke.
UDP sender med andre ord pakken ud over bakkerne og glemmer alt om den, mens TCP sender pakken og sidder pænt og venter på en kvittering fra modtageren om at pakken er modtaget.
Din garanti er at du vil få det at vide hvis TCP ikke kan aflevere pakken til modtager, mens UDP ikke vil give dig denne oplysning og du vil fejlagtigt tro at pakken er modtaget. Jeg ved det ikke men jeg vil tror at TCP venter et vist tidsrum på en kvittering, og hvis denne ikke kommer timer afsendelsen ud, og man får en fejlmeddelelse. Så kan man jo sende pakken igen. UDP venter ikke på noget som helst og din afsendelse er en succes, hvis blot pakken forlader din maskine, så at sige.

Hvis directplay påstår at, de kan garantere levering af pakken (hvilket ingen kan - man kan kun garantere aflevering/kvittering eller time out), så må de selv have implementeret en kvitteringsmekanisme under UDP. De må så at sige have kode kvitteringsfunktionaliteten fra TCP med UDP-pakker istedet.

Garantere pakke-aflevering ?!?!?! Det er som at garantere at S-toget kører, og det vil være noget naivt. Det MÅ være noget Microsoft har fundet på.

Du må altså kode din egen kvitteringmekanisme under UDP, som garanterer en kvittering eller time out (på kvitteringen). Alternativt må du anvende et API som giver dig denne funktionalitet.

Der ligger mange interessante problemer her og jeg tror, at du vil blive meget klogere af at arbejde med dem ;)

Held og lykke,
                Morten .....

Ja ordkløveri, man kan lige så godt sige: TCP _KAN_ garantere din applikation at at en pakke er afleveret. Sætter man retransmission til uendelig, vil din pakke blive afleveret ! Det er kun et sprøgsmål om tid.

Det var absolut ikke min mening at anfægte din forklaring chries. Den er skam korrekt.
Jeg er blot harm over at nogen har givet krismort den opfattelse, at man kan garantere pakken modtagelsen. Det er nemlig meget vigtig når man opbygger distribuerede systemer at man holder for øje at man ikke kan regne med at de andre noder svarer. Går man i gang med at kode udfra den forudsætning at ens pakker altid bliver afleveret er man på gyngende grund. Dead-lock-problemet springer i øjnene her..
En god regel er altid at regne med at ens transmissioner før eller siden går galt og tage højde for dette.

btw, du kan godt sætte retransmission til uendelig men det garantere kun at din pakke vil blive FORSØGT afleveret uendelig mange gange.

Morten

Hvis der nu var tale om et char program hvor alle clienter kun har forbindelse til server og ikke nogen af de andre clienter. Så har jeg et problem hvis jeg bruger udp.
Hvis der er en ny client som joiner på serveren så skal serveren sende en pakke til alle andre clienter om at nu skal de altså tilføje endnu en client på deres clientliste. Hvis denne pakke ikke kommer frem (det ved vi jo ikke) så bliver clienten aldrig tilføjet hvis pakken kommer frem og clienter sender et response "ja jeg har modtaget pakken med dette serie nummer" og denne pakke aldrig når til serveren vil serveren tro at clienten ikke har modtaget pakken om at clienten skal tilføje den nye client. Derfor prøver serveren at sende endnu en pakke om at clienten skal oprettes på serveren.
Jeg ved godt at dette kan løses med lappeløsninger men man kunne nok godt tænke sig problemer hvor det ville være svært at opstille hvis og hvis løsninger .

Kristian

Jeg tror ikke du skal lade din server opdatere klienterne - så er den pludslig afhængig af at kunne få fat i alle sammen. Lad istedet klienterne bede serveren om klient-listen og chat-teksten. Betragt din server som en dum slave der kun laver hvad klienten beder den om. Det skal helst være serveren ligemeget hvad der sker med klienterne. Serveren skal bare svare på de request som kommer ind og ikke forsøge den store administration (det er jo ikke flybilletter der sælges).
Jeg tror du skal forsøge en pull-metode hvor klienter trækker information udfra serveren istedet for en push-metode hvor server forsøge at opdatere alle klienter.
Lad dine klienter bede om chat-tekst og klient-liste et par gange i sekundet eller lignende....
Morten