Re: Pořadí packetů

[Petr Labaj]

To píšete, jak si představujete, že by to mělo fungovat?

V praxi to totiž funguje jinak.
Odesílání dat si řídí odesilatel, přijímač do toho nemá co kecat a 
někoho vyzývat.
Potvrzování v TCP je tzv. okénkové potvrzování, kdy přijímač potvrdí, 
která poslední
data dostal OK, takže ta už odesilatel nemusí dál držet v bufferu. Do 
doby, než to
ten Rx potvrdí, tak Tx musí tato data stále držet v bufferu pro případný 
retransmit.
Potvrzená data nemusí být všechna odeslaná, je to prostě posouvající-se 
ukazatel,
co už je doručeno OK. Takže příjemce klidně může potvrdit jen příjem 
poloviny
dat, odeslaných v jednom rámci, a později pak potvrdí ten zbytek atd. Je 
to asynchronní
proces.

Balení dat do jednotlivých rámců závisí na odesilateli. Je-li to možné, 
je dobré
použít explicitně flush() tehdy, kdy to má význam. Pak to má aplikace 
provoz pod kontrolou
a nezatěžuje síť zbytečnými malými rámci (což hrozí při Nodelay a 
nevhodném plnění Tx
bufferu), ale ani nezdržuje provoz čekáním na timeouty pro odeslání 
zbylých dat.

PL

**********************

Dne 9.5.2016 v 14:09 Jiří Nesvačil napsal(a):
>
> Zdravim,
>
> jeste jsem hledal, asi to bude o stesti na implementaci TCP/IP stacku. 
> Behem tech 200ms muze projit pozadavek na dalsi data, ale spise to 
> bude o spatne/stare implementaci IP stacku.
>
> Spise se doporucuje vyhnout tomu No Delay a poslat do bufferu vice, 
> tim pripadne si snizite zatez na tom CPU. Nebo aspon budete vedete, co 
> Vam ten wireshark zobrazuje.
>
> https://blogs.technet.microsoft.com/nettracer/2013/01/05/tcp-delayed-ack-combined-with-nagle-algorithm-can-badly-impact-communication-performance/
>
> Jirka
>
>