RE: Problems with SO_REUSEADDR
- From: v-terryf@xxxxxxxxxxxxxxxxxxxx ("TerryFei")
- Date: Tue, 21 Mar 2006 03:10:02 GMT
Hi Matthias,
Welcome to MSDN Newsgroup!
The definition of SO_REUSEADDR, as defined by Richard Stevens,is the
following. Note it is very clear in stating that tcp sockets should never
allow the binding on EXACT duplicateaddress (ie, IP and ports).
The SO_REUSEADDR socket option serves four different purposes :
1. SO REUSEADDR allows a listening server to start and bind its well-known
port even if previously established connections exist that use this port as
their local port. This condition is typically encountered as follows:
(a) A listening server is started.
(b) A connection request arrives and a child process is spawned to handle
that client.
(c) The listening server terminates but the child continues to service the
client on the existing connection.
(d) The listening server is restarted.
By default, when the listening server is restarted in (d) by calling
socket, bind, and listen, the call to bind fails because the listening
server is trying to bind a port that is part of an existing connection (the
one being handled by the previously spawned child). But if the server sets
the SO_ REUSEADDR socket option between the calls to socket and bind, the
latter function will succeed. All TCP servers should specify this socket
option to allow the server to be restarted in this situation.
This scenario is one of the most frequently asked questions on
Usenet.
2. SO_REUSEADDR allows multiple instances of the same server to be started
on the same port, as long as each instance binds a different local IP
address. This is . common for a site hosting multiple HTTP servers using
the IP alias technique (Section A.4). Assume the local host's primary IP
address is 198.69.10.2 but it has two aliases of 198.69.10.128 and
198.69.10.129. Three HTTP servers are started. The first HTTP server would
call bind with a local IP address 198.69.10.128 and a local port of 80 (the
well-known port for HTTP). The second server would bind198.69.10.129 and
port 80. But this second call to bind fails unless so_ REUSEADDR is set
before the call. The third server would call bind with the wildcard as the
local IP address and a local port of 80. Again, SO_REUSEADDR is required
for this final call to succeed. Assuming SO_REUSEADDR is set and the three
servers are started, incoming TCP connection requests with a destination IP
address of 198.69.10.128 and a destination port of 80 are delivered to the
first server, incoming requests with a destination IP address of
198.69.10.129 and a destination port of 80 are delivered to the second
server, and all other TCP connection requests with a destination port of 80
are delivered to the third server. This final server handles requests
destined for 198.69.10.2 in addition to any other IP aliases that the host
may have configured. The wildcard means "everything that doesn't have a
better (more specific match." Note that this scenario of allowing multiple
servers for a given service is handled automatically if the server always
sets the so_ REUSEADDR socket option (as we recommend).
With TCP we are never able to start multiple servers that bind the same 11'
address and the same port: a completely duplicate binding I. That is,
cannot cannot start one server that binds 198.69.10.2 port 80 and start
another that also binds 198.69.10.2 port 80, even if we set the so_
REUSEADDR socket option for the set-ond server.
3. SO_REUSEADDR allows a single process to bind the same port to multiple
sockets, as long as each bind specifies a different local IP address. This
is common for UDP servers that need to know the destination IP address of
client requests on systems that do not provide the IP_RECVDSTADDR socket
option, and we develop an example using this technique in Section 19.]1.
This technique is normally not used with TCP servers since a TCP server can
always determine the destination IP address by calling getsockname after
the connection is estab-
4. SO_REUSEADDR allows completely duplicate bindings a bind of an IP
address and port, when that same IP address and port are already bound
to another socket Normally this feature is supported only on systems
that support multicasting when that system does not support the so
_REUSEPORT socket option (which we describe shortly), and only for UDP
sockets (multicasting does not work with TCP)
This feature is used with multicasting to allow the same application to
be run multiple times on the same host. When a UDP datagram is received
for one of these multiply bound sockets, the rule is that if the
datagram is destined for either a broadcast address or a multicast
address, one copy of the datagram is delivered to each matching socket.
But if the datagram is destined for a unicast address, the datagram is
delivered to only one socket. If, in the case of a unicast datagram,
there are multiple sockets that match the datagram, which one of the
sockets will receive the datagram is implementation dependent. Pages
777-779 of TCPv2 talks more about this feature. We talk more about
broadcasting and multicasting in Chapters 18 and 19.
WinNT appears to allow the bind of "exact duplicate" addresses for
tcp sockets. This means that if a customer starts a server process
with a listening endpoint that is exactly the same as an already
existing process' listening endpoint, instead of getting the
correct error EADDRINUSE, it succeeds! It appears to variable
whether the first or second server will receive the incoming
requests...
I hope the above information is helpful for you. Thanks and have a nice day!
Best Regards,
Terry Fei[MSFT]
Microsoft Community Support
Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)
--------------------
Thread-Topic: Problems with SO_REUSEADDRmicrosoft.public.win32.programmer.networks:29576
thread-index: AcZMbKEaPb64cSgaQg6zx1bQje5udw==
X-WBNR-Posting-Host: 217.91.67.185
From: =?Utf-8?B?TWF0dGhpYXMgTW9ldGplIFtNVlBd?= <moetje@xxxxxxxxxxxxxxxx>
Subject: Problems with SO_REUSEADDR
Date: Mon, 20 Mar 2006 14:21:27 -0800
Lines: 45
Message-ID: <A5707677-AA19-4518-AC42-832688B511C2@xxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: 7bit
X-Newsreader: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830
Newsgroups: microsoft.public.win32.programmer.networks
Path: TK2MSFTNGXA03.phx.gbl
Xref: TK2MSFTNGXA03.phx.gbl
NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250
X-Tomcat-NG: microsoft.public.win32.programmer.networks
Hi,
I have a problem with the SO_REUSEADDR socket option
which does not behave as expected.
I have to set up two sockets, each one is living within a COM
object (same process, different thread).
One socket is for sending, the other one for receiving RTP
packets. Both need to be bound to the same local IP address
and port (the receiver must receive on the same sockaddr
that the sender uses to send from).
I am unable to reuse the socket because the COM objects
are controlled from a different process (thus I can't create
the socket once and pass it to both COM objects).
The only solution I found was to use the SO_REUSEADDR
option to be able to bind both sockets to the same local
address. I am doing it this way:
1. Create rxSocket
2. Bind rxSocket to local sockaddr
3. Create txSocket
4. Set SO_REUSEADDR option on txSocket
5. Bind txSocket to local sockaddr (same as 2)
Now the result is as follows: Sending always works
correctly, but I am only sometimes able to receive
UDP packets on rxSocket. The behaviour seems
to change randomly.
Am I doing something wrong? When I want to send
on one socket and receive on the other socket both
bound to the same sockaddr what is the correct procedure,
which socket should I bind first? Should I set SO_REUSEADDR
on both sockets or only on one?
Why do I get random behaviour?
Thanks for any hints!
Best regards,
Matthias Moetje
.
- Follow-Ups:
- Re: Problems with SO_REUSEADDR
- From: Matthias Moetje [MVP]
- Re: Problems with SO_REUSEADDR
- Prev by Date: Re: Problems with SO_REUSEADDR
- Next by Date: Re: Problems with SO_REUSEADDR
- Previous by thread: Re: Problems with SO_REUSEADDR
- Next by thread: Re: Problems with SO_REUSEADDR
- Index(es):
Relevant Pages
|