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 _______________________________________________ Devel mailing list [email protected] http://openser.org/cgi-bin/mailman/listinfo/devel
