TCP/IP Socket - TCP flags

die push flag moet je aankrijgen met setsockopt en TCP_NODELAY.

Maar ik denk niet dat dit het probleem is.

Die push is bedoeld om de andere kant te vertellen dat ie NU de app wakker moet schudden en niet moet verwachten dat er nog meer data komt.

er is ook NAGLE.... als je zeg 200 bytes stuurt, dan past er vast nog wel meer data in een packet. Het os wacht met het aanmaken van het packet totdat er een timeout verstrijkt. Maar dit speelt op 100ms tijdschaal....

Voor mij is de hamvraag of je meting wel klopt. Hoe meet je wat je meet? Waar draai je die wireshark? Hoe zie je dat het op linux langzamer is?

De TCP_NODELAY optie is al ingeschakeld. Deze disabelen het Nagle's algoritme. Dit was ook mooi te zien met WireShark. Met het Nagle's algoritme aan werd er gewacht met het sturen van data tot het pakketje vol zat. Nu dit uitgeschakeld is worden de pakketjes direct verstuurd.

De TCP_NODELAY optie is ingeschakeld zowel aan de client kant als aan de server kant. Toch is de push optie aan de serverkant niet enabled.

Ik meet met WireShark aan de client side. Ik weet niet precies hoe dit gemeten word maar dit programma leest ieder pakketje uit. Alle inkomende en uitgaande pakketten worden met dit programma uitgelezen. Hierbij wordt ook de tijd weergeven hoelang het pakketje erover gedaan heeft.

maar... stel dat een pakketje 200us "op de draad" zit. (is overdreven ik weet het).

Stel nu op t= 0us stuurt je client een pakketje data. OS denkt even na, bouwt een TCP pakketje en staat op het punt om de boel op de draad te gooien. Wireshark grijpt in en tapt het pakketje af. Dat is misschien op t=10 us. Timestamp 10us. Nu gaat het op de draad en komt op t=210us aan op de server. Die verwerkt het en heeft op t=230us een antwoord klaar. Weer 200us op de draad en op 430 komt het binnen op je client. Wireshark zal nu een timestamp van 430 of 440 er op plakken.

Hoe kan je hieruit nu concluderen dat de server WACHT met het zenden van data?

Ik geloof dat het gebruik van de push flag uit de mode is geraakt. In een ver verleden was het "wakkerschudden" van een server of een client nog een heel werk. Op sommige machines een significant deel van een hele seconde. Dan wil je van de andere kant een indicatie hebben van of het programma nog meer zal willen zien of dat het nu "verwerkbaar" is. Tegenwoordig minder relevant. Je zet het proces gewoon op de runnable queue en als dat onterecht blijkt, dan kunnen er twee dingen gebeuren: Je had het druk, hij is nog niet aan de beurt gekomen en ondertussen is de rest toch binnen, of je had het niet druk en hebt in de wachttijd even het programma wakkergemaakt en weer in slaap gesust.

Een beperking van ethernet is dat een pakket pas afgelopen mag zijn als alle hosts op het netwerk het begin van het pakket hebben gezien, rekening houdend met looptijden en zo. Voor 100mbps upgrade vanaf 10mbs hebben ze vooral de maximum netwerk-lengte omlaag gebracht. Bij 100 naar 1000mpbs was dat niet langer een optie: De maximum lengte komt gewoon best regelmatig voor. Dus hebben ze de minimum pakketlengte omhoog moeten gooien. Een minmaal pakket op 1000mbps duurt dus ongeveer even lang als op 100mbps!

Dat geldt alleen bij half duplex, ik denk dat het merendeel van de bedrade ethernet verbindingen - bij winkels en bedrijven maar ook thuis - tegenwoordig switched fullduplex point-to-point verbindingen zijn.

Misschien is de TS meer gebaat bij het gebruik van UDP, waarmee je de overhead van TCP kwijt bent.

In de eerste instantie zou je denken dat de beperking niet meer zou hoeven gelden, als het full-duplex is.

Maar wat doet een hub als je met twee hosts tegelijk gaat lopen sturen naar een derde? 1 of 2 pakketjes opslaan kan nog wel. Maar op een gegeven moment is het op. Dan moet ie het versturen van pakketjes van de hosts gaan beperken. Dus de link van de computer naar de hub moet nog steeds aan de lengte beperking voldoen. De minimale packetlengte is nog steeds van kracht, wordt geimplementeerd en is op gigabit ethernet met moderne hardware prima te meten.

Up to 448 padding bytes may be sent for small packets.

van https://www.cse.wustl.edu/~jain/cis788-97/ftp/gigabit_ethernet/index.h…

Dat is een document uit 1997, toen 100Mb net ingevoerd was en gigabit ethernet nog in de kinderschoenen stond. Men nam in die tijd nog aan dat Gigabit ethernet ook over shared-segment netwerken (dus domme hub's) verzonden zou moeten kunnen worden.

Gigabit ethernet is tegenwoordig vrijwel altijd point-to-point, volledig geswitched en fullduplex. Die padding wordt tegenwoordig niet meer gebruikt.

Je kan het zelf controleren met iperf. Met 488 bytes padding zouden er niet meer dan 200k pps over de draad kunnen gaan.

Flow control is een apart mechanisme hier worden (soms) ethernet pause frames gebruikt. Vroeger werd dit wel eens gedaan door collisions te simuleren, maar aangezien tegenwoordig bijna alles fullduplex is zou dat niet meer werken.

[Bericht gewijzigd door joopv op maandag 11 september 2017 13:36:58 (18%)

OK. Geinig. Nooit te oud om te leren.

[Bericht gewijzigd door rew op maandag 11 september 2017 18:13:32 (46%)