[Serdev] TCP problems

[Katty Xiong]

--- Nils Ohlmeier <nils at iptel.org> wrote:

> On Friday 12 January 2007 11:01, Klaus Darilion
> wrote:
> > Yes, I've seen this problem too. Somehow we get a
> deadlock. the
> > application's don't read anymore as they are
> blocked during sending.
> >
> > Not sure if the problem is in ser, sipp or in both
> applications - I
> > could not find a solution. Maybe you have more
> luck.
> >
> > Nevertheless it shows that an application must be
> programmed in a
> > non-blocking way.
> 
> Sorry just for my own understanding: how should
> non-blocking sending solves 
> this problem?

SIPp use one thread to send and receive packets. If
send blocks, the thread cannot drain packets from
receiving buffer, thus TCP @ SIPp eventually publicize
zero window. When TCP at both SER and SIPp has zero
window, no data exchange occurs. After a while, SER
aborts this idle connection and creates a new
connection.

If send() at SIPp is non-blocking, so at least SIPp
can still receive packets, and deadlock will not
occur.

SIPp uses non-blocking send() actually, but somehow
after sending window close, the non-blocking send()
blocks. Don't know why yet.

> If the application sends in a non-blocking way and
> the OS can't send the data 
> over the link as fast as the application is trying
> to send, the OS have to 
> store the data in some kernel internal buffer,
> right?
> So what happens if this internal buffer is full? I
> guess the OS would either 
> give an error back to the application or would block
> the application until 
> the internal buffer has enough space to take the new
> data.

In non-blocking send, if kernel buffer is full, send()
returns a EWOULDBLOCK error.

Joy

> So to me it seems like sending in a non-blocking way
> only increases the delay 
> until the application "recognizes" the problem
> (except the link somehow 
> speeds up in the meantime and the internal buffer is
> freed - then the buffer 
> would bypass the short "outage" of the link - but we
> are not talking here 
> about short "outages" of links).
> 
> Maybe I'm overlooking here something
>   Nils
> 



 
____________________________________________________________________________________
We won't tell. Get more on shows you hate to love 
(and love to hate): Yahoo! TV's Guilty Pleasures list.
http://tv.yahoo.com/collections/265