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

[Steven Gong]

Walter,
Thanks for the information. One thing that should be noticed is that
tcpnodelay is not a Java/Mina option but an OS option. And in the thread you
provided, I have the impression that MINA 2.0 and MINA 1.x have different
behaviors while sending packets. So does that mean it is the MINA
implementation that causes this delay issue? Notice that Red5 is using MINA
1.x currently.

Again back to tcpnodelay. I doubt if the following comment is correct:
This allows the operating system to send all the data in a single IP packet
regardless of the tcpnodelay setting.
If the tcpnodelay is set to true, a correct implementation of OS should
always send the TCP packet to the IP layer without pending.

On 11/6/07, Walter Tak <walter at waltertak.com> wrote:
>
> >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
>
>
>
> _______________________________________________
> Red5 mailing list
> Red5 at osflash.org
> http://osflash.org/mailman/listinfo/red5_osflash.org
>



-- 
Best Regards
Steven Gong

InfraRed5 Red5 Consultant: http://www.infrared5.com, steven at infrared5.com

Red5 Developer: http://osflash.org/red5,
http://jira.red5.org/confluence/display/~steven/Home

Modesty is an overrated quality in men of no great accomplishment.  -- Ricky
Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://osflash.org/pipermail/red5_osflash.org/attachments/20071106/58e0c534/attachment-0001.html