Re: SetSockOpt with SO_REUSEADDR parameter

mmlab_js schrieb:

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 [http://support.microsoft.com/kb/192570]

That article talks about a TCP server, so some things are different here.

1) Server listen on port 9898
Fine.
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
Wrong.
UDP does not have the concept of a "connection". That's why UDP is called a "connectionless protocol".
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
Wrong.
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
Wrong.
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 port.
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 object.


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 do?

Your server could do something like this:

create socket #1 and bind to port 9898
create socket #2 and bind to port 9899

for (;;)
{
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
}
}

Thread:
while (not done)
{
send next fragment to client:
call SendTo on socket #2 with client's sockaddr
}

Some notes:

* 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!

Norbert
.

Relevant Pages

  • Re: Winsock / Sockets programming
    ... At the client side receive message from the server only, ... socket on one port. ... And connect everybody to that socket like a big ...
    (microsoft.public.vc.mfc)
  • Re: Possible bug in .Net 2.0 udp sockets?
    ... assumption that the port which the client sees is the same as the port ... get the correct endpoints under simple circumstances. ... multiple outstanding BeginReceiveFrom's on a UDP socket are not supported, ...
    (microsoft.public.dotnet.framework)
  • Re: Winsock / Sockets programming
    ... At the client side receive message from the server only, ... A target of a network connection is a <ip-address, socket#> pair. ... outside the walls of your environment, you should apply to IANA for a Registered Port ... the client has to know the IP address of each potential server. ...
    (microsoft.public.vc.mfc)
  • Re: VB.NET Socket - Multiple clients to server
    ... Private MySocket As Socket ... Dim ipHostInfo As IPHostEntry = Dns.GetHostByName) ... 'Looping periodically on MyTcpListener to see if any client try to ... And I wouldn't have to care anymore with port number? ...
    (microsoft.public.dotnet.languages.vb)
  • Re: VB.NET Socket - Multiple clients to server
    ... Private MySocket As Socket ... Dim ipHostInfo As IPHostEntry = Dns.GetHostByName) ... 'Looping periodically on MyTcpListener to see if any client try to ... And I wouldn't have to care anymore with port number? ...
    (microsoft.public.dotnet.general)