TCP/IP, maximaal aantal pakketten per keer?

[Verwijderd]

Hallo,

Ik weet niet of deze vraag hier thuis hoort, maar wist geen ander forum/sectie waar zo'n vraag kon worden gesteld.

Ik ben op het moment bezig met een hardware project, om een standalone shoutcast client te maken. Het hele shoutcast gebeuren loopt over TCP/IP, en dit gedeelte van de firmware werkt al aardig, ik kan bijvoorbeeld al inloggen op een shoutcast server. Hierna treed het probleem ook op: De shoutcast server begint de stream te verzenden. Zo af en toe verzend de shoutcast 2 keer een pakketje, nog voordat ik de eerste geacknowlegded heb. De tijd hiertussen is ongeveer 10µs. Het probleem is dat mijn hardware hier te traag voor is, wanneer het 2e pakketje verzonden is, ben ik nog bezig om het eerste pakketje op te slaan. Het is zelfs zo dat de hardware het niet eens door heeft dat er nog een pakketje verzonden is. Uiteraard volgt er wel een retransmission van het 2e pakketje, maar dit is pas 5 seconden later, dan loopt de stream natuurlijk wel lekker achter als het zo 1 van de 6 pakketjes gaat

Nu zat ik te denken, is het mogelijk om bij TCP of IP ergens op te geven dat er eerst een pakketje geacknowledged behoort te worden voordat de volgende wordt verzonden, of dat het mogelijk is om de minimale tijd tussen 2 te verzenden pakketjes door te geven? Ik heb al flink gezocht op google, maar niets gevonden helaas, en begin het ergste te vrezen...

Alvast bedankt!
Wouter

[leuk_he]

Ik dacht dat dat standaard in tcp al zo geregeld werd.


zie b.v:

http://www.informit.com/a...sp?p=130716&seqNum=4&rl=1

dus in ieder geval controleren of niet perongeluk in de client een TCP_NODELAY socket optie is meegegeven (fout fout zou ik zeggen in diet geval), of dat dat in de server geforceerd nagle uitzeget is.

Google keywoorden: nagle slowstart TCP_NODELAY

[Verwijderd]

Bedankt voor je antwoord, maar ik ben bang dat dat het niet is. Het is sowieso dat de 2 pakketjes elk 1460 (=waarde van mss, pakketje volledig vol dus) databytes bevat. Helaas kan ik aan de server kant ook niets veranderen, het is namelijk de bedoeling dat ik de meeste shoutcast servers kan ontvangen.

Ik zal nog even proberen wat extra uitleg te geven waar ik naar opzoek ben: Ik zou eigenlijk de server duidelijk moeten maken dat hij pas het volgende pakketje verzend wanneer hij een ack heeft ontvangen van het vorig door de server verzonden pakketje. Nu is het zo dat hij er soms 2 achterelkaar verstuurd, of hij nu een ack op de eerste heeft ontvangen of niet, zo snel dat ik het 2e pakketje mis.

[serkoon]

Dit wordt geregeld door de window size van TCP. Je kunt jouw maximale window adverteren als 1460, zodat er maximaal 1 vol pakket 'uit mag staan' richting jou. Die zal dus eerst acknowledged moeten worden voordat een nieuwe komt. Wat je moet doen is dus jouw receive window verkleinen. Vanuit BSD-sockets kan dit door de buffer-grootte te verkleinen met setsockopt, optie SO_RCVBUF.

Voor iets als shoutcast lijkt me dit echter verre van ideaal, helemaal als je verder ook op andere plekken geen buffering doet..

[Verwijderd]

serkoon schreef op maandag 24 april 2006 @ 22:20:
Dit wordt geregeld door de window size van TCP. Je kunt jouw maximale window adverteren als 1460, zodat er maximaal 1 vol pakket 'uit mag staan' richting jou. Die zal dus eerst acknowledged moeten worden voordat een nieuwe komt. Wat je moet doen is dus jouw receive window verkleinen. Vanuit BSD-sockets kan dit door de buffer-grootte te verkleinen met setsockopt, optie SO_RCVBUF.

Aan zoiets had ik idd ook al gedacht... Maja, is nu natuurlijk niet echt een nette oplossing. Maar ik ga dan geen problemen krijgen dat de server bijvoorbeeld 2 pakketjes van 700 bytes oid snel achter elkaar gaat verzenden? Dan heb ik natuurlijk alsnog een probleem.

Voor iets als shoutcast lijkt me dit echter verre van ideaal, helemaal als je verder ook op andere plekken geen buffering doet..

Helaas is de enigste buffer die ik heb idd een TCP buffer.

Ik denk dat ik dan eens de window size maximaal op 1460 in ga stellen, en kijken hoe dat gaat. Mocht iemand nog een nettere oplossing hebben, ik hoor het natuurlijk dan graag

iig bedankt!

[serkoon]

Verwijderd schreef op dinsdag 25 april 2006 @ 12:15:
Aan zoiets had ik idd ook al gedacht... Maja, is nu natuurlijk niet echt een nette oplossing. Maar ik ga dan geen problemen krijgen dat de server bijvoorbeeld 2 pakketjes van 700 bytes oid snel achter elkaar gaat verzenden? Dan heb ik natuurlijk alsnog een probleem.

Dat zou in theorie kunnen. In de praktijk wordt meestal gebruik gemaakt van grotere buffers, liefst in pagesizes, dus 4096 bytes of meervouden daarvan, zodat de mss wel gehaald wordt.

Feit blijft dat het niet echt een ideale situatie is.Eigenlijk zou je netwerkkaart al veel meer moeten kunnen bufferen dan maar 1 pakket, zou je IP queueing moeten doen (aangezien er fragmentatie kan zijn van IP) en zou je liefst ook nog out-of-order TCP kunnen vreten. Dat laatste is echter niet per se nodig, en omdat je met TCP werkt kom je zelfs nog weg met het niet ondersteunen van IP fragmentatie.. maar toch