[Devel] tcp keepalive question

[Dan Pascu]

On Tuesday 19 December 2006 14:06, Juha Heinanen wrote:
> Dan Pascu writes:
>  > IMO, OpenSER's architecture is well suited for UDP clients and at
>  > most some TCP/TLS peers. But even in this case if a peer is down and
>  > there are many connection towards that peer, again many TCP workers
>  > will be blocked, and other TCP peers cannot be handled meanwhile.
>
> dan,
>
> how does this differ from the case where UDP UAS is down and does not
> respond and openser tm module keep re-sending the request until timeout
> occurs?

On second thought, in OpenSER's case since it has asymmetric processing 
for requests/replies, the issue can be solved without an event reactor 
based architecture by marking the connections as non-blocking and if 
OpenSER gets a WOULD_BLOCK error to a write attempt, it can return a 
negative reply immediately as it knows the connection is down (and I 
would guess it already does this).

Sorry for the confusion. I was thinking of a standard TCP channel that 
unlike UDP may block on write and where a request is met by a reply 
immediately, and if the reply doesn't come the connection will return 
only after a timeout. But in our case I guess we can ignore this as we do 
not have to wait for the answer right away as it will be processed later 
by another worker.

I would say that in this case, given the asymmetric processing of requests 
and replies, the event reactor is somehow implicit in the design.

So please forget the issue I raised. I was thinking of a different 
scenario that doesn't apply in OpenSER's case.

-- 
Dan