[Red5] High latency with red5 [tcpnodelay / tcp_nodelay]

[Walter Tak]

>Have you set the tcp_nodelay?

I read that that changing tcpnodelay / tcp_nodelay has no effect since it's 
the OS that sends the packets to the real world, not Java / Mina.

Check out 
http://www.nabble.com/how-to-guarantee-flushed-write-in-encoder---mina-2.0.0-M1-snapshot-t4568900s16868.html

Might be useful.

Quote from that url (for users that will use a searchengine to learn about 
this problem) :

When MINA 2.0 writes pending messages, it loops until either all the
pending message have been written to the OS or until it can't send any
more data without blocking because the OS' write buffer for the socket
is full.  So, MINA is receiving each of your individual ByteBuffer (now
IoBuffer) objects and writing them in rapid succession.  This allows the
operating system to send all the data in a single IP packet regardless
of the tcpnodelay setting.  MINA is not doing any mering of your
messages.  The operating system is doing this.  IIRC, MINA 1.x will
write a ByteBuffer and then resume writing once the data in the
ByteBuffer is flushed by the OS.  So, MINA 2.0 is much more efficient
and can more effectively use the OS' write buffer.

As Niklas was saying, you should not have a protocol that depends on TCP
packet boundaries which is what you appear to be doing.  It is perfectly
valid for routers and proxies to concatenate or split TCP packets.  So
when Server X or Client Y receives a packet and a messageReceived event
is triggered, per your example, it is possible that the received
ByteBuffer contains multiple requests or responses.

You can not assume that 3 IoSession.write()'s will result in 3
messageReceived events on the remote host.  n IoSession.write()'s will
result in m messageReceived events on the remote host and m can be ANY
number greater than 1.  That means that a single IoSession.write() could
result in multiple messageReceived events or multiple
IoSession.write()'s could result in a single messageReceived event.
And, of course, it is possible (and often common) for m and n to be equal.

You do bring up a good point that you can't flush the write queue from 
within messageReceived.  I'll file a JIRA issue for this.
Mike Heath-4



-- 
I am using the free version of SPAMfighter for private users.
It has removed 13727 spam emails to date.
Paying users do not have this message in their emails.
Get the free SPAMfighter here: http://www.spamfighter.com/len