Re: SetSockOpt with SO_REUSEADDR parameter
I write a server application to send real-time video frame to client(s).
When a client logins into server, I will create a UDP socket to send
real-time video frame to it.
So, I think I will use multiple sockets with the same port to send frame.
Is this concept wrong?
Yes, it is wrong.
In UDP, a socket stands for a local endpoint. This endpoint is described by the
local machine's IP address and a local port number. As soon as you bind a local
port number to the socket, the port is used and can not be bound again. It can
not be reused until you close the socket. (The best you can get using
SO_REUSEADDR is that the second bind steals the port number away from the first
socket, making it unusable. But I am not sure what SO_REUSEADDR really does.)
The reason I use mutiple UDP is the beginning of this response.
Because I will send real-time video frame, I use UDP socket.
Ok, so far so good, as long as your client can handle lost video frames.
I will re-describe my idea. The basic architecture is based on the source
That article talks about a TCP server, so some things are different here.
1) Server listen on port 9898
Note that UDP sockets do not "listen" as TCP sockets do.
Listening on a UDP socket means the server creates a socket, binds a local port
number to it and waits for incoming data. No calls to Listen or Connect allowed.
2) Client spawns a thread, which connects to the server
UDP does not have the concept of a "connection". That's why UDP is called a
When you refer to "connect" here I assume you mean that the client calls a
function named Connect. However, this does not establish a connection to a UDP
server. It only tells the socket library that all UDP traffic will happen
between that named remote site, so there is no need to specify the remote
server's address with every send/recv call.
3) Server accepts the connection and spawns a thread to handle the socket
communication and send real-time frame
UDP sockets do not have an acceept functionality. The server receives a UDP
frame on its one and only single openen UDP socket. Then it has to check the
sender's address and check if that address/port number specifies a client that
wants to receive video data.
4) The thread creates a UDP socket with port 9899
The server must create exactly one global socket on that port to prepare for
client traffic. The threads can not each create a socket and bind to that single
Instead, all clients use the same socket to stream the video data to the
clients. That's what the SendTo function is made for. So each thread may talk to
one single client, but it does so by calling SendTo on the same global socket
5) The thread sends the real-time frame with UDP socket to client.
So, I think I need one UDP socket for one client.
No, see #4 above.
It still can't work for create UDP sockets with the same port. What shall I
Your server could do something like this:
create socket #1 and bind to port 9898
create socket #2 and bind to port 9899
Wait for data on socket #1
if data available
read the data using RecvFrom.
recvfrom tells you the sockaddr of the client
create a thread for that client, passing it the client's sockaddr
while (not done)
send next fragment to client:
call SendTo on socket #2 with client's sockaddr
* You could do all this with only one socket on the server. You can sen dand
receive on the same socket from different threads.
* This design still has problems in high load situations. Since UDP does not
have flow control, you would lose packets when you send more data then the local
network adapter can handle. One way would be to send only when you "can" send
(indicated by the OnSend callback). But since you only have one socket for all
threads, you only have one callback that had to be shared by all threads. You
see, there is still work left for you to do!