Re: Listening and Establish TCP connections on/from the same IP end po
- From: "Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx>
- Date: Mon, 16 Feb 2009 22:24:59 -0800
On Mon, 16 Feb 2009 21:41:01 -0800, aaronc <aaronc@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
"aaronc" wrote:
Hi,
I have an application that needs to use the same IP end point to both listen
and accept client connections as well as be able to establish connections to
external TCP sockets. The application is a SIP server and the requirement it
has is to be able to accept SIP requests from clients and then to forward
those requests onto additional SIP servers.
The application needs to listen on a specific port because that's where the
clients will be attempting to connect. For the outgoing calls it needs to use
the same port, 5060, as a lot of firewalls will be configured to accept
traffic originating from 5060 and drop anything else.
With UDP it's simple to listen and send from the same IP end point but as
yet I have not been able to find a way to do it with TCP.
Turned out to be very easy after all...
socket.SetSocketOption(SocketOptionLevel.Socket,
SocketOptionName.ReuseAddress, true);
Um, no.
That does allow you to create a new socket using the same IP/port as an existing socket.
But it does not allow both sockets to actually _use_ that IP/port at the same time, nor would there be any reliable way to let that happen.
The most common use of ReuseAddress is to allow a new server (listening) socket to be created even though a previous one is still in the TIME_WAIT state, and even that use of the property is risky (TIME_WAIT exists because there may actually be data enroute that hasn't arrived yet, and which might confuse a newly created socket...bypassing that protection creates a risk of exactly that confusion happening).
My recollection is that when used with two existing sockets, ReuseAddress results in the most recently bound socket getting all the network data. But even if somehow you found a network provider that didn't simply disable the earlier-bound sockets, there'd be no way to reliably route incoming IP packets to the right socket.
Fortunately, it's HIGHLY unlikely that you actually need this. Your statement that "For the outgoing calls it needs to use the same port, 5060, as a lot of firewalls will be configured to accept traffic originating from 5060 and drop anything else" doesn't make sense to me. Client ports are pretty much _never_ assigned according to protocol, and firewalls don't block inbound traffic based on the sender's port at all. If they did, then you'd need your web browser to always bind to port 80 (for example) just to get data to a web server.
Your SIP proxy can just create normal client sockets for the purpose of connecting to "additional SIP servers". Just bind the port as 0 and let the network stack choose a port for you. That should work just fine (assuming, of course, those other servers are behind properly configured firewalls such that connection requests targeted at _their_ port are properly forwarded, but that should be a given).
Pete
.
- References:
- Prev by Date: RE: Listening and Establish TCP connections on/from the same IP end po
- Next by Date: RE: Saving data to a database (multiple tables)
- Previous by thread: RE: Listening and Establish TCP connections on/from the same IP end po
- Index(es):
Relevant Pages
|
