---

Hej



Dette spørgsmål har jeg også postet i en programmerings gruppe men jeg
regner med at der er en del her der også ved en masse om den slags.



Jeg skal lave et program der sender en UPD pakke til ca. 3500 servere i hele
verden, hver server svarer så tilbage med mellem 1 og 4 UDP pakker. At sende
pakkerne er jo ikke noget problem men kort tid efter de er sendt og stadig
mens jeg er ved at sende begynder UDP pakkerne at vælte ind fra de
forskellige servere. Spørgsmålet er så kan man regne med at modtage alle de
ankomne pakker eller vil en stor del af dem gå tabt fordi der simpelthen
kommer for mange, og dem der går tabt hvor går de tabt henne. TDC har vel
ingen problemer med at modtage dem så det må jo være fra TDC og ud til mig
de mistes?



De data jeg sender til serverne fylder ca. 10 byte mens hver server svarer
tilbage med total ca. 550 byte fordelt på 1-4 pakker.



Jeg har ikke lavet programmet endnu da jeg lige ville hører andres meninger
først, men hvis man skal forvente at miste en del ankomne pakker hvad vil så
være den bedste metode til at undgå dette?



Mvh

HK

---

Harald wrote:
> Jeg skal lave et program der sender en UPD pakke til ca. 3500 servere i hele

Dette kan være svært i sig selv, hvilket OS bruger du og hvilke kort?

> verden, hver server svarer så tilbage med mellem 1 og 4 UDP pakker. At sende

Worst case får du 14000 pakker tilbage, hvilket et almindeligt ethernet
kort ikke kan følge med.

> De data jeg sender til serverne fylder ca. 10 byte mens hver server svarer
> tilbage med total ca. 550 byte fordelt på 1-4 pakker.

I worst case, nemlig at du modtager al trafik i samme sekund, vil det
kræve en 15Mbit forbindelse.

> Jeg har ikke lavet programmet endnu da jeg lige ville hører andres meninger
> først, men hvis man skal forvente at miste en del ankomne pakker hvad vil så
> være den bedste metode til at undgå dette?

Hvad skal programmet bruges til.

---

"Christian E. Lysel" <chlyshoswmdatapunktumcom@example.net> skrev i en
meddelelse news:3D41B32B.10407@example.net...
> Harald wrote:
> > Jeg skal lave et program der sender en UPD pakke til ca. 3500 servere i
hele
>
> Dette kan være svært i sig selv, hvilket OS bruger du og hvilke kort?

Programmet er til windows 2k/XP, kortene er nok i de fleste tilfælde
standard netkort af dem til 175,- man kan købe i enhver computer biks.

> > verden, hver server svarer så tilbage med mellem 1 og 4 UDP pakker. At
sende
>
> Worst case får du 14000 pakker tilbage, hvilket et almindeligt ethernet
> kort ikke kan følge med.

> > De data jeg sender til serverne fylder ca. 10 byte mens hver server
svarer
> > tilbage med total ca. 550 byte fordelt på 1-4 pakker.
>
> I worst case, nemlig at du modtager al trafik i samme sekund, vil det
> kræve en 15Mbit forbindelse.

Et godt gæt vil være at ping på serverne er fra 30 til 300ms så chancen for
at alle kommer på een gang er meget lille.

> > Jeg har ikke lavet programmet endnu da jeg lige ville hører andres
meninger
> > først, men hvis man skal forvente at miste en del ankomne pakker hvad
vil så
> > være den bedste metode til at undgå dette?
>
> Hvad skal programmet bruges til.

Til at hente game info fra spil servere placeret rundt omkring i verden.

Mvh
HK

---

Harald wrote:
> Programmet er til windows 2k/XP, kortene er nok i de fleste tilfælde
> standard netkort af dem til 175,- man kan købe i enhver computer biks.

Det hjælper ikke på situationen, jeg ville nok købe et bedre kort.

Seriøst du skal ikke regne med at kunne smide 2000-4000 pakker i
sekundet på et billigt kort.

>>I worst case, nemlig at du modtager al trafik i samme sekund, vil det
>>kræve en 15Mbit forbindelse.
> Et godt gæt vil være at ping på serverne er fra 30 til 300ms så chancen for
> at alle kommer på een gang er meget lille.

Ved du at 300ms er 0.3 sekunder?

Over hvor stort et tidsinterval vil du smide de 3500 request afsted?
(jeg forstod det oprindeligt som du ville smide dem hurtigst muligigt
afsted, men du har faktisk ikke skrevet om det).

---

"Christian E. Lysel" <chlyshoswmdatapunktumcom@example.net> skrev i en
meddelelse news:3D41C86D.7080001@example.net...
> Harald wrote:
> > Programmet er til windows 2k/XP, kortene er nok i de fleste tilfælde
> > standard netkort af dem til 175,- man kan købe i enhver computer biks.
>
> Det hjælper ikke på situationen, jeg ville nok købe et bedre kort.

Der er vel ikke mange der har en internet forbindelse der er så hurtig at
det kan være et problem.

> Seriøst du skal ikke regne med at kunne smide 2000-4000 pakker i
> sekundet på et billigt kort.
>
> >>I worst case, nemlig at du modtager al trafik i samme sekund, vil det
> >>kræve en 15Mbit forbindelse.
> > Et godt gæt vil være at ping på serverne er fra 30 til 300ms så chancen
for
> > at alle kommer på een gang er meget lille.
>
> Ved du at 300ms er 0.3 sekunder?

Ja.

> Over hvor stort et tidsinterval vil du smide de 3500 request afsted?
> (jeg forstod det oprindeligt som du ville smide dem hurtigst muligigt
> afsted, men du har faktisk ikke skrevet om det).

De vil blive smidt så hurtig afsted som den internet forbindelse brugeren nu
har kan klare. Samtidig venter programmet på svar fra de 3500 servere.

Det letteste er nok at lave et test program, så det vil jeg gøre i morgen.

Mvh
HK

---

Harald wrote:
>>>Programmet er til windows 2k/XP, kortene er nok i de fleste tilfælde
>>>standard netkort af dem til 175,- man kan købe i enhver computer biks.
>>Det hjælper ikke på situationen, jeg ville nok købe et bedre kort.
> Der er vel ikke mange der har en internet forbindelse der er så hurtig at

Du kan leje et skab hos en ISP, og få acces via et LAN.

> det kan være et problem.

En 2Mb forbindelse vil kunne transportere 5000 pakker (pr. sek.) af den
mindste størrelse. Dit netværkskort kan dog ikke følge med.

Ved en 512Kb forbindelse (1000 pakker) vil dit netværk kort godt kunne
følge med, og hvis dit netværkkort kan producere 3000 pakker, vil du
have et pakketab på 2/3.

Hvor stor en forbindelse har du?

>>Seriøst du skal ikke regne med at kunne smide 2000-4000 pakker i
>>sekundet på et billigt kort.

>>Ved du at 300ms er 0.3 sekunder?
> Ja.

Ergo, vil svarene komme inde for næsten det samme sekund.

>>Over hvor stort et tidsinterval vil du smide de 3500 request afsted?
>>(jeg forstod det oprindeligt som du ville smide dem hurtigst muligigt
>>afsted, men du har faktisk ikke skrevet om det).
> De vil blive smidt så hurtig afsted som den internet forbindelse brugeren nu
> har kan klare. Samtidig venter programmet på svar fra de 3500 servere.

Hvordan vil du smide det afsted så hurtigt som internet forbindelsen kan
klarer det, hvordan vil du måle det?

Dit netværkskort vil blot smide det ud på dit ethernet, om routeren kan
følge med er afhængig af hvilken router det er. Når routeren eller din
forbindelse ikke kan klarer mere vil pakkerne blot dø, da du bruger UDP,
og du vil intet få at vide om disse pakke tab.

Hvis du har en ordenlig router, vil den umiddelbare begrænsning ligger i
dit netværkskort.


Ovenstående "beregninger" er kun for udgående trafik. Hvis vi også skal
regne indgående trafik med kan du i worst case få et pakketab på 5/6. Vi
har stadigvæk ikke regnet med at du nu skal retransmittere.


Hvis jeg var dig ville jeg nok gå efter at sende de 3500 pakker over et
størrer tidsinterval, fx over et minut, hvilket giver 60 pakker i sekundet.

> Det letteste er nok at lave et test program, så det vil jeg gøre i morgen.

Eller finde et, kik fx efter ttcp

---

Hej Harald,

Harald wrote:
> Til at hente game info fra spil servere placeret rundt omkring i verden.

Som du nu nok har bemaerket, saa kan du ikke forvente at modtage all
dine pakker, og dem du modtager kan sandsynligvis ogsaa komme i
"forkert" raekkefoelge.

Det mest almindelige er vist, i saadan en situation, at du skal tage
nogle forbehold:

1. Altid have "nok" information til at vide at du har modtaget "alt" fra
en server
2. Hvis ikke du har modtaget "nok" fra en server, send dit spg. igen
3. Put alle spg i en queue, saa du kan begraense maengden af udgaaende
pakker, baseret paa antallet af inkommende pakker.

Send foerts et spg. Naar du modtager "nok" fra den server, proev at send
det dobbelte antal spg. Hvis de baegge er OK, sende det dobbelte igen
.... hvis du oplevet "tab" (antal ligmend X), saa reducer ned til det
halve af det nuvaerrende (ca. X/2). Tillad en "grace" perriode (eg.
300ms) hvor du kan have tab, men sende hastigheden er stabil. Herefter
oeget du antallet af spg. med en, to, fire, ... osv igen. Hvis du har
tab (antal ligmed Y) a) inden du er naaet op paa X igen, gaa tilbage til
det halve af foroegelsen (ca. (X-Y)/2) eller b) efter du er naaet over
X, gaa tilbage til det halve af det nuvaerrende (Y/2). [ Hver gang du
har tab, bliver X == Y ]

Det betyder at du skulle kunne sende noget der ligner det optimale antal
spg., baseret paa antallet af svar der kommer ind.

Du faar under alle omstaendingheder ikke ret meget ud af at sende 3500
spg. og saa vente paa svar.

Martin

---

"Martin Djernaes" <martin@djernaes.dk> skrev i en meddelelse
news:3D456435.AD7043FE@djernaes.dk...
> Hej Harald,
>
> Harald wrote:
> > Til at hente game info fra spil servere placeret rundt omkring i verden.
>
> Som du nu nok har bemaerket, saa kan du ikke forvente at modtage all
> dine pakker, og dem du modtager kan sandsynligvis ogsaa komme i
> "forkert" raekkefoelge.
>
> Det mest almindelige er vist, i saadan en situation, at du skal tage
> nogle forbehold:
>
> 1. Altid have "nok" information til at vide at du har modtaget "alt" fra
> en server
> 2. Hvis ikke du har modtaget "nok" fra en server, send dit spg. igen
> 3. Put alle spg i en queue, saa du kan begraense maengden af udgaaende
> pakker, baseret paa antallet af inkommende pakker.
>
> Send foerts et spg. Naar du modtager "nok" fra den server, proev at send
> det dobbelte antal spg. Hvis de baegge er OK, sende det dobbelte igen
> ... hvis du oplevet "tab" (antal ligmend X), saa reducer ned til det
> halve af det nuvaerrende (ca. X/2). Tillad en "grace" perriode (eg.
> 300ms) hvor du kan have tab, men sende hastigheden er stabil. Herefter
> oeget du antallet af spg. med en, to, fire, ... osv igen. Hvis du har
> tab (antal ligmed Y) a) inden du er naaet op paa X igen, gaa tilbage til
> det halve af foroegelsen (ca. (X-Y)/2) eller b) efter du er naaet over
> X, gaa tilbage til det halve af det nuvaerrende (Y/2). [ Hver gang du
> har tab, bliver X == Y ]
>
> Det betyder at du skulle kunne sende noget der ligner det optimale antal
> spg., baseret paa antallet af svar der kommer ind.
>
> Du faar under alle omstaendingheder ikke ret meget ud af at sende 3500
> spg. og saa vente paa svar.

Nej det har jeg prøvet og det kom der self. ikke noget godt ud af, kun ca.
400 af de 3500 spg. nåede ud :).

Jeg tror ikke din løsning er helt brugbar da man nødvendigvis skal have en
lille pause mellem hver udsendt spg. og det skal så være pausen mellem hver
udsendt spg. man skal variere afhængig af hvor hurtig ens linie er.

Jeg har tænkt på noget ligende dette: Jeg starter med at sende spg. ud med
en lille pause mellem hver spg. Jeg vil derefter for hvert sekund kikke på
hvor mange spg. der er afsendt og hvor mange komplette svar der er modtaget,
hvis de modtagne svar er under 90% vil pausen mellem udsendte spg. forøges
og hvis der modtages over 90% vil pause blive forminsket.
Hvis jeg får svar på mindre end 90% må det være fordi der udsendes for mange
spg. og hvis jeg modtager mere end 90% så er det nok fordi linien godt kan
klare lidt mere.
Listen med de ca. 3700 servere ændres hele tiden og man skal ikke forvente
at der er flere end ca. 93% af serverne der er aktive.
Så efter nogle få sekunder burde pause mellem hver spg. være rimelig stabil
men naturligvis varierer lidt. Jeg har kørt adskillige test på de 3700
servere og mængden af data der modtages når der sendes spg. til alle ligger
hver gang meget stabil, det er naturligvis fordi at de ca. 250 døde servere
altid er pænt fordelt ned igennem listen af servere.

Procenterne skal muligvis ændres lidt op/ned.

Mvh
HK

---

Hej,

Harald wrote:
> Jeg tror ikke din løsning er helt brugbar da man nødvendigvis skal have en
> lille pause mellem hver udsendt spg. og det skal så være pausen mellem hver
> udsendt spg. man skal variere afhængig af hvor hurtig ens linie er.

Pausen er jo bygget ind i forslaget Der er bare en modificeret
version af TCPs "slow start" - soeg paa googl for gode ideer.


> Listen med de ca. 3700 servere ændres hele tiden og man skal ikke forvente
> at der er flere end ca. 93% af serverne der er aktive.

Fast tal er altid daarlige. Du skulle heller tillade x retransmisioner
og derefter enten vente til en rolig stund til at proeve et par gange
igen, eller droppe serveren i denne omgang.


> Procenterne skal muligvis ændres lidt op/ned.

Ja, men det ville du ikke have brug for i mit forslag. Dit eget forslag
er dog sikkert simpler at implementere, og hvis det er "godt nok <tm>"
til dig, ja saa vaersgo :)

Martin

---

"Martin Djernaes" <martin@djernaes.dk> skrev i en meddelelse
news:3D46B83C.A8D84ACF@djernaes.dk...
Hej,

Harald wrote:
>> Jeg tror ikke din løsning er helt brugbar da man nødvendigvis skal have
en
>> lille pause mellem hver udsendt spg. og det skal så være pausen mellem
hver
>> udsendt spg. man skal variere afhængig af hvor hurtig ens linie er.

>Pausen er jo bygget ind i forslaget Der er bare en modificeret
>version af TCPs "slow start" - soeg paa googl for gode ideer.

Ja men med dit forslag når jeg med en 1024/256 down/up linie op på at kunne
sende 220 spg. ad gangen (har testet det), men så er jeg nød til at vente på
at alle svarene er ankommet inden jeg sender de næste 220 spg., og det tager
min. 1.5 sek. (har testet det) dvs. med 3700 servere vil den samlede tid
blive ca. ((3700/220) * 1.5) = 25 sek.

Med mit forslag hvor jeg kører med næsten max DL hele tiden bliver tiden
(har igen testet det) ca. 19 sek.

Men det er meget mulig at jeg ikke helt har forstået dit forslag :), jeg vil
prøve at kikke efter TCPs "slow start"

Mvh
HK

---

Hej,

Harald wrote:
> >Pausen er jo bygget ind i forslaget Der er bare en modificeret
> >version af TCPs "slow start" - soeg paa googl for gode ideer.
>
> Ja men med dit forslag når jeg med en 1024/256 down/up linie op på at kunne
> sende 220 spg. ad gangen (har testet det), men så er jeg nød til at vente på
> at alle svarene er ankommet inden jeg sender de næste 220 spg., og det tager
> min. 1.5 sek. (har testet det) dvs. med 3700 servere vil den samlede tid
> blive ca. ((3700/220) * 1.5) = 25 sek.

Hvis du siger det, skal det nok passe :)

Jeg gaar ud fra at "problemet" er at jeg regnede med at alle server
skulle vaere der. Hvis du har en eller flere servere der ikke svare, saa
falder mit forslag tilbage til (ca) x/2. Hvis du har mange servere der
ikke er til staede (sige du ikke i en anden mail at du havede ca 5-7%
"daarlige" servere?), saa er jeg sikker paa at min vil "kloejs" i det.
Du kunne sikkert oege funktionaliteten ved at sige "en fejl er ingen
fejl" og saa bruge 'n' som treshold for fejl ...

> Med mit forslag hvor jeg kører med næsten max DL hele tiden bliver tiden
> (har igen testet det) ca. 19 sek.

Ja men det er jo udemaerket

Det eneste jeg har imod "dit forslag" er at du (ogsaa) er afhaengig at
faktore som "antallet af daarlige server" og at du nemt kan komme til at
overfylde din forbindelse under afsendelse af spg. da du kunne sende
flere spg. end du har plads til at modtage.

Din upling er 1/4 af din dnlink. Dit spg er 1/55 af et svar. Hvis du
sender saa mange spg som du kan, saa kan du ikke modtage alle dine svar
:(

Martin

---

"Martin Djernaes" <martin@djernaes.dk> skrev i en meddelelse
news:3D46DD5C.F892503A@djernaes.dk...
Hej,

<klip en bunke>

>Det eneste jeg har imod "dit forslag" er at du (ogsaa) er afhaengig at
>faktore som "antallet af daarlige server" og at du nemt kan komme til at
>overfylde din forbindelse under afsendelse af spg. da du kunne sende
>flere spg. end du har plads til at modtage.

>Din upling er 1/4 af din dnlink. Dit spg er 1/55 af et svar. Hvis du
>sender saa mange spg som du kan, saa kan du ikke modtage alle dine svar
>:(

Jeg vil blive ved med at sende flere og flere spg/sek indtil jeg begynder at
kunne se at jeg mister data, så vil spg/sek blive sat ned. Programmet vil så
huske denne spg/sek værdi til næste gang det startes og så starte med denne.
Hvis brugeren så skulle have gang i noget andet DL/UL så vil værdien blive
ændret.

Men om jeg nu vælger den ene eller anden løsning så er det bedere end det
program jeg havde før hvor en komplet scan tog 40 sek. så det er da ca. en
halvering af tiden :)

Men tak for alle svarene, jeg har da fået nogle ideer og fået en masse
prøvet af.

Mvh
HK

---

Harald wrote:
> Men tak for alle svarene, jeg har da fået nogle ideer og fået en masse
> prøvet af.

Velbekom :)

Martin

---

On Fri, 26 Jul 2002 22:19:09 +0200, "Harald" <swobu@kroning.dk>
wrote:

> Jeg skal lave et program der sender en UPD pakke til ca. 3500 servere i hele
> verden, hver server svarer så tilbage med mellem 1 og 4 UDP pakker. [...]
> Spørgsmålet er så kan man regne med at modtage alle de ankomne pakker

Nej.

Når du vælger at bruge en forbindelsesløs protokol er det op til
dit program at holde styr på, hvilke svar du i givet fald mang-
ler.

Jeg tror, du mangler en basal forståelse af, hvad UDP er for en
protokol. Jeg vil foreslå, du starter på www.net-faq.dk og kigger
på de links der refereres til for UDP.

> eller vil en stor del af dem gå tabt fordi der simpelthen kommer for mange

Det afhænger jo af en række parametre, såsom din forbindelses
hastighed, serverens hastighed, dit programs effektivitet etc.
Ja, det er mere end muligt, at et antal af svarene vil blive
droppet et eller flere steder mellem afsenderen og dig.

> Jeg har ikke lavet programmet endnu da jeg lige ville hører andres meninger
> først, men hvis man skal forvente at miste en del ankomne pakker hvad vil så
> være den bedste metode til at undgå dette?

Ja, det må du jo håndtere i din programmering, når du vælger at
bruge UDP.

-A
--
Heroes: Vint Cerf & Bob Kahn, Leonard Kleinrock, Robert Metcalfe, Jon Postel
Links : http://www.hojmark.org/networking/
FAQ : http://www.net-faq.dk/

---

"Asbjorn Hojmark" <Asbjorn@Hojmark.ORG> skrev i en meddelelse
news:s5g3ku0lc8jemr5takdba8kfo2e1ulchga@news.worldonline.dk...
> On Fri, 26 Jul 2002 22:19:09 +0200, "Harald" <swobu@kroning.dk>
> wrote:
>
> > Jeg skal lave et program der sender en UPD pakke til ca. 3500 servere i
hele
> > verden, hver server svarer så tilbage med mellem 1 og 4 UDP pakker.
[...]
> > Spørgsmålet er så kan man regne med at modtage alle de ankomne pakker
>
> Nej.
>
> Når du vælger at bruge en forbindelsesløs protokol er det op til
> dit program at holde styr på, hvilke svar du i givet fald mang-
> ler.
>
> Jeg tror, du mangler en basal forståelse af, hvad UDP er for en
> protokol. Jeg vil foreslå, du starter på www.net-faq.dk og kigger
> på de links der refereres til for UDP.

Næ jeg ved udemærket hvad UDP er. Det jeg mangler en forståelse af er hvad
der sker når der kommer rigtig mange UDP pakker til TDC som alle skal sendes
videre til min computer.

> > eller vil en stor del af dem gå tabt fordi der simpelthen kommer for
mange
>
> Det afhænger jo af en række parametre, såsom din forbindelses
> hastighed, serverens hastighed, dit programs effektivitet etc.
> Ja, det er mere end muligt, at et antal af svarene vil blive
> droppet et eller flere steder mellem afsenderen og dig.
>
> > Jeg har ikke lavet programmet endnu da jeg lige ville hører andres
meninger
> > først, men hvis man skal forvente at miste en del ankomne pakker hvad
vil så
> > være den bedste metode til at undgå dette?
>
> Ja, det må du jo håndtere i din programmering, når du vælger at
> bruge UDP.

Det er ikke noget jeg vælger, det er de servere jeg spørger som kun kan
benytte UDP.

Mvh
HK

---

On Fri, 26 Jul 2002 23:53:45 +0200, "Harald" <swobu@kroning.dk>
wrote:

> Det jeg mangler en forståelse af er hvad der sker når der kommer
> rigtig mange UDP pakker til TDC som alle skal sendes videre til
> min computer.

Hvis TDC ikke kan sende dem til dig (fx. fordi din forbindelse er
overbelastet af de mange pakker), så dropper TDCs udstyr simpelt-
hen pakken.

Det samme er i øvrigt tilfældet alle andre steder på vejen, hvor
der måtte være congestion, ligesom det samme ville ske med andre
protokoller end UDP, men nogle andre protokoller (som TCP) søger
selv for at holde styr på, hvad der er sendt og modtaget, så der
kan foretages retransmissioner.

>> Ja, det må du jo håndtere i din programmering, når du vælger at
>> bruge UDP.

> Det er ikke noget jeg vælger, det er de servere jeg spørger som
> kun kan benytte UDP.

Som sagt, så må du i din programmering holde styr på, hvilke
servere, du har fået svar fra, og spørge dem igen, hvis du ikke
har fået noget.

-A
--
Heroes: Vint Cerf & Bob Kahn, Leonard Kleinrock, Robert Metcalfe, Jon Postel
Links : http://www.hojmark.org/networking/
FAQ : http://www.net-faq.dk/

---

Asbjorn Hojmark skrev:
> Som sagt, så må du i din programmering holde styr på, hvilke
> servere, du har fået svar fra, og spørge dem igen, hvis du ikke
> har fået noget.

Eller det som man har modtaget er mangelfuldt, forvansket, dupleret,
kommer i forkert række følge eller andet "sjovt"...

-------
Tomas