TCP/IP window size

[Verwijderd]

Mijn vraag heeft betrekking tot de window size binnen de TCP header. Mij is inmiddels duidelijk dat hiermee bepaald kan worden na hoeveel data een bevestiging verstuurd moet worden dat de data binnen is.

Wat ik echter niet weet is of de data dan al "binnen is". Geeft de protocolstack de data al vrij aan de applicatie zodra de data binnen is of pas nadat de acknowledge gegeven is?

[leuk_he]

De vraag is niet helemaal logisch. Zodra data binnen is wordt die aan de applicatie meteen (als de checksum/volgorde klopt) doorgegeven. De ack verzenden heeft enkel tot gevolg dat de zender zijn buffer vrijgeeft zodat hij opnieuw meer kan gaan zenden.

Wellicht je vraag wat uitgebreider stellen?

http://www.ncsa.uiuc.edu/...cp_windows.html#what%20is

What is this TCP Window Thing?

A TCP window the amount of outstanding (unacknowledged by the recipient) data a sender can send on a particular connection before it gets an acknowledgment back from the receiver that it has gotten some of it.

For example if a pair of hosts are talking over a TCP connection that has a TCP window size of 64 KB (kilobytes), the sender can only send 64 KB of data and then it must stop and wait for an acknowledgment from the receiver that some or all of the data has been received. If the receiver acknowledges that all the data has been received then the sender is free to send another 64 KB. If the sender gets back an acknowledgment from the receiver that it received the first 32 KB (which could happen if the second 32 KB was still in transit or it could happen if the second 32 KB got lost), then the sender could only send another 32 KB since it can't have more than 64 KB of unacknowledged data outstanding (the second 32 KB of data plus the third).

[MeatGrinder]

Verwijderd schreef op maandag 03 oktober 2005 @ 09:58:
Mijn vraag heeft betrekking tot de window size binnen de TCP header. Mij is inmiddels duidelijk dat hiermee bepaald kan worden na hoeveel data een bevestiging verstuurd moet worden dat de data binnen is.

Dit is niet correct, deze informatie kan niet uit de window size worden afgelezen. De advertised window is een weergave van de buffercapaciteit van de zender (doorgaans is dit de maximale waarde van 65535 bytes). Dit staat los van het 'ACK beleid' welke ook niet volledig is vastgelegd in de RFC's en dus deels implementatie afhankelijk is.

Wat ik echter niet weet is of de data dan al "binnen is". Geeft de protocolstack de data al vrij aan de applicatie zodra de data binnen is of pas nadat de acknowledge gegeven is?

Ik veronderstel dat alle in volgorde ontvangen data direct beschikbaar is voor de applicatie, ik zou niet weten waarom niet.

[Verwijderd]

Okay ik zal het wat uitgebreider stellen. Ik ga hierbij uit van het volgende voorbeeld:

http://www.rawether.net/support/KB06300101.htm#SmallPacket

Volgens dit voorbeeld wordt een acknowledge op de helft van de window tijd gestuurd. Men gaat uit van een stream aan pakketen. Ik vroeg me af of je pakket 1 t/m 127 al in je applicatie kunt verwerken voordat de aknowledge verstuurd is door de protocolstack.

Misschien begrijp ik het voorbeeld wel verkeerd

[MeatGrinder]

Verwijderd schreef op maandag 03 oktober 2005 @ 11:38:
Volgens dit voorbeeld wordt een acknowledge op de helft van de window tijd gestuurd.

In het voorbeeld wordt kunstmatig laat ge-ACKed, ze zorgen ervoor dat er precies een ACK aankomt bij de sender op het moment dat het transmit window (=minimum van congestion & advertised window) op 0 staat. Normaal gesproken ACK je veel vaker, immers als de ACK wat vertraging oploopt kan je even niets meer verzenden.

Men gaat uit van een stream aan pakketen. Ik vroeg me af of je pakket 1 t/m 127 al in je applicatie kunt verwerken voordat de aknowledge verstuurd is door de protocolstack.

Ik denk niet zozeer dat dit een applicatie probleem is tenzij je heel erg low-level werkt, waarschijnlijk lees en schrijf je gewoon naar een socket en dan ben je afhankelijk van wat je TCP stack je aanlevert en daar moet je het mee doen. Ik zie overigens (nog steeds) geen reden waarom de stack de data niet direct beschikbaar zou stellen aan de applicatie als de checksum goed was en de data in volgorde aankwam.

[Verwijderd]

Ik werk inderdaad vrij low level. Inmiddels computernetwerken van tanenbaum maar weer van stal gehaald. Ik zat inderdaad mis in de ack constructie. Elk afzonderlijk bericht krijgt een ack in de vorm van hetzelfde TCP frame maar dan zonder data. De ack's kunnen dus echter behoorlijk achterlopen met het verzenden en daar zorgt de window size dan voor.

Volgens mij was dat de strekking van het verhaal.

[MeatGrinder]

Verwijderd schreef op dinsdag 04 oktober 2005 @ 09:26:
Ik werk inderdaad vrij low level. Inmiddels computernetwerken van tanenbaum maar weer van stal gehaald. Ik zat inderdaad mis in de ack constructie. Elk afzonderlijk bericht krijgt een ack in de vorm van hetzelfde TCP frame maar dan zonder data. De ack's kunnen dus echter behoorlijk achterlopen met het verzenden en daar zorgt de window size dan voor.

Volgens mij was dat de strekking van het verhaal.

Een goede TCP implementatie zal er voor zorgen dat de ACKs nooit 'behoorlijk achterlopen'. Het hele mechanisme van TCP is er op gebaseerd om een verbinding zo goed mogelijk te benutten, en daarom zal de transmit window altijd proberen om de link capaciteit (Bandwidth-Delay Product) te benaderen. Als je je ACKs lange tijd delayed zal je periodes hebben dat je niet kan zenden doordat je transmit window op nul staat of je moet op een of andere manier zorgen dat je transmit window overgedimensioneerd is waardoor je na ontvangst van een ACK meer pakketten dan de link capaciteit verzend met congestion als gevolg.

Lees Tanenbaum nog eens aandachtig door, ik weet zeker dat de werking van TCP er correct instaat. Bekijk evt. ook section 4.2 van RFC2581 m.b.t. delayed ACKs.

[Verwijderd]

Duidelijk, ik bedoelde echter dat het voorbeeld:

http://www.rawether.net/support/KB06300101.htm#SmallPacket

de ack behoorlijk laat achterlopen