<div class="gmail_quote">On Tue, Jun 9, 2009 at 08:31, Bruce Simpson <span dir="ltr"><<a href="mailto:bms@incunabulum.net">bms@incunabulum.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Bruce Simpson wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
With most TCP/IP implementations, the MTU of the loopback interface will be 65535 bytes. As you probably know already, the segment size used by a TCP session is going to be negotiated upfront during the 3 way handshake.<br>
</blockquote>
<br></div>
Sorry, I meant to say 16384 bytes here (at least, that's the default in FreeBSD). It can usually be tweaked upwards.<br>
<br>
In any event, whilst the MTU of the loopback interface will affect XORP XRL IPC transport, the loopback MTU is *usually* sufficiently large not to cause problems with the socket4.xif, unless you are attempting to send IPv6 jumbograms.<br>
<br>
cheers,<br>
BMS<br>
</blockquote></div><br>Thanks for the reply, I was using TCP sockets with IPv4 packets, that's why I thought XORP would handle the merging, but I saw the comment in IoTcpUdpSocket::send():<br><pre> // We don't coalesce for TCP as well, but this could be changed in the<br>
// future if it improves performance.<br><br></pre>I think the socket library should indicate to the programmer when it's going to split the packet being sent.<br><br>Cheers,<br>Victor<br>