<html>
<head>
<meta content="text/html; charset=iso-8859-2"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Jak pozna prijimaci sptrana, ze vysilac nereagoval na ACK?</p>
<p>Pouze tak, ze vysilac OPAKOVAL predchozi data (retranslace).</p>
<p>Ale to neni pozadavek na dalsi data. To je jen potvrzeni
prijatych dat.</p>
<p>Info pro vysilac, ze je muze zahodit z bufferu.</p>
<p>Na retranslaci vysilac reaguje jednak snizenim rychlosti
odesilani a jednak prodlouzenim timeoutu.</p>
<p>Otazkou je, jestli jste nahodou neresil problem s keepalive.</p>
<p><a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/Keepalive">https://en.wikipedia.org/wiki/Keepalive</a><br>
</p>
<p>Povodni diskuze o 200ms je popsana zde:</p>
<p><a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/Transmission_Control_Protocol">https://en.wikipedia.org/wiki/Transmission_Control_Protocol</a><br>
</p>
<h3><span class="mw-headline" id="Forcing_data_delivery">Forcing
data delivery</span></h3>
<p>Normally, TCP waits for 200 ms for a full packet of data to send
(<a href="https://en.wikipedia.org/wiki/Nagle%27s_Algorithm"
title="Nagle's Algorithm" class="mw-redirect">Nagle's Algorithm</a>
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.</p>
<p>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.</p>
<p>Setting the <a
href="https://en.wikipedia.org/wiki/Network_socket"
title="Network socket">socket</a> option <code>TCP_NODELAY</code>
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.</p>
<p>The RFC defines the <code>PSH</code> push bit as "a message to
the receiving TCP stack to send this data immediately up to the
receiving application".<sup id="cite_ref-comer_2-8"
class="reference"><a
href="https://en.wikipedia.org/wiki/Transmission_Control_Protocol#cite_note-comer-2">[2]</a></sup>
There is no way to indicate or control it in <a
href="https://en.wikipedia.org/wiki/User_space" title="User
space">User space</a> using <a
href="https://en.wikipedia.org/wiki/Berkeley_sockets"
title="Berkeley sockets">Berkeley sockets</a> and it is
controlled by <a
href="https://en.wikipedia.org/wiki/Protocol_stack"
title="Protocol stack">Protocol stack</a> only.<sup
id="cite_ref-Stevens2006_21-0" class="reference"><a
href="https://en.wikipedia.org/wiki/Transmission_Control_Protocol#cite_note-Stevens2006-21">[21]</a></sup></p>
<p>Slavek<br>
</p>
On 9.5.2016 17:30, Jiųķ Nesvačil wrote:<br>
<blockquote cite="mid:d06e58bf-1de4-f8e1-1087-23655a0ecb5d@posys.cz"
type="cite">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.
<br>
Detail bych musel nekde prohrabat, oni ty zakladni poucky o TCP
jsou pekne ... .
<br>
Jirka
<br>
<br>
<br>
Dne 9. 5. 2016 v 16:37 Slavomir Skopalik napsal(a):
<br>
<blockquote type="cite">
<br>
Dobry den,
<br>
<br>
ale jak vyzve/upozorni?
<br>
<br>
Tj. jaky posle paket?
<br>
<br>
Slavek
<br>
</blockquote>
</blockquote>
<br>
</body>
</html>