Re: Pořadí packetů

[Slavomir Skopalik]

Jak pozna prijimaci sptrana, ze vysilac nereagoval na ACK?

Pouze tak, ze vysilac OPAKOVAL predchozi data (retranslace).

Ale to neni pozadavek na dalsi data. To je jen potvrzeni prijatych dat.

Info pro vysilac, ze je muze zahodit z bufferu.

Na retranslaci vysilac reaguje jednak snizenim rychlosti odesilani a 
jednak prodlouzenim timeoutu.

Otazkou je, jestli jste nahodou neresil problem s keepalive.

https://en.wikipedia.org/wiki/Keepalive

Povodni diskuze o 200ms je popsana zde:

https://en.wikipedia.org/wiki/Transmission_Control_Protocol


      Forcing data delivery

Normally, TCP waits for 200 ms for a full packet of data to send 
(Nagle's Algorithm <https://en.wikipedia.org/wiki/Nagle%27s_Algorithm> 
tries to group small messages into a single packet). This wait creates 
small, but potentially serious delays if repeated constantly during a 
file transfer. For example, a typical send block would be 4 KB, a 
typical MSS is 1460, so 2 packets go out on a 10 Mbit/s ethernet taking 
~1.2 ms each followed by a third carrying the remaining 1176 after a 
197 ms pause because TCP is waiting for a full buffer.

In the case of telnet, each user keystroke is echoed back by the server 
before the user can see it on the screen. This delay would become very 
annoying.

Setting the socket <https://en.wikipedia.org/wiki/Network_socket> option 
|TCP_NODELAY| overrides the default 200 ms send delay. Application 
programs use this socket option to force output to be sent after writing 
a character or line of characters.

The RFC defines the |PSH| push bit as "a message to the receiving TCP 
stack to send this data immediately up to the receiving 
application".^[2] 
<https://en.wikipedia.org/wiki/Transmission_Control_Protocol#cite_note-comer-2> 
There is no way to indicate or control it in User space 
<https://en.wikipedia.org/wiki/User_space> using Berkeley sockets 
<https://en.wikipedia.org/wiki/Berkeley_sockets> and it is controlled by 
Protocol stack <https://en.wikipedia.org/wiki/Protocol_stack> only.^[21] 
<https://en.wikipedia.org/wiki/Transmission_Control_Protocol#cite_note-Stevens2006-21> 


Slavek

On 9.5.2016 17:30, Jiří Nesvačil wrote:
> Pokud to dobre davam zpetne, tak to souvisi s tim delay ACK. Prijimaci 
> strana pokud ma pocit, ze odesilaci nereagovala na ACK, tak jej posle 
> znovu. S tim jsem se setkal, ze nestacilo tech 200ms a chodili mi 
> dalsi packety navic, zdrzovalo to. Nebyl jen jeden a az pote 
> nasledoval delsi timeout. Ono to je docela logicke, pokud chcete 
> rychli prenos, tak kdyz se Vam ztrati jeden packet, tak musite ihned 
> zareagovat a necekat dlouho.
> Detail bych musel nekde prohrabat, oni ty zakladni poucky o TCP jsou 
> pekne ... .
> Jirka
>
>
> Dne 9. 5. 2016 v 16:37 Slavomir Skopalik napsal(a):
>>
>> Dobry den,
>>
>> ale jak vyzve/upozorni?
>>
>> Tj. jaky posle paket?
>>
>> Slavek

------------- další část ---------------
HTML příloha byla odstraněna...
URL: <http://list.hw.cz/pipermail/hw-list/attachments/20160509/c893480c/attachment.html>