Ok, guys, thnaks for your comments, but it was my mistake when I did not introduce the core of my question. Let's imagine a use case. You have a stateless proxy and this proxy receives incomming requests and forwards them. When proxy uses TCP it has to open client connection. When proxy requests to open client connection, OS creates a TCP channel with 2 sockets - remote socket where to send and another one is a local socket on your host. Unfortunately the number of sockets is limited by a big number - 65535 and when your stateless proxy should process 1000 incomming requests per second you will reach the limit very fast - 65 seconds. In this case when to close client connection is very important. In case of transaction stateful entities you know about transaction and you have to maintain connection opend during transaction, in case of stateless one - when to close is not defined. That is why I think the stateless proxy should close TCP connection ASAP and to close connection immediately after forwarding an incomming request is the only way to process 1000 incomming TCP requests per second.
----- Original Message ----- From: "Brett Tate" <[EMAIL PROTECTED]> To: "Victor Tsoukanov" <[EMAIL PROTECTED]>; <[email protected]> Sent: Wednesday, February 07, 2007 7:43 PM Subject: RE: [Sip-implementors] Stateless Proxy and TCP transport > > > So, in the case of a stateless proxy, > > > the TCP connection would close > > > once the SIP request had been successfully > > > sent. So, the connection for the response > > > would "Fail" and the response would be sent > > > to the sent-by (generally). > > > > Ideally ! I prefer this solution :) - to close client > > connection immediately after forwarding and explanation ! > > Yes, this might work and is allowed. However my understanding of the > best common practice these days is to keep sip related tcp connections > up until they need to be reclaimed. This helps reduce delays and > processing overhead introduced by devices choosing to open and close tcp > connections for each transaction or dialog. > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
