Multi-Threaded server which can handle UDP, TCP clients

Hello there,

I would like to implement a multi-threaded server which can accept
requests from both TCP as well as UDP clients. Can anyone suggest how
to proceed for this?

After contemplating it, following are my doubts regarding the
implementation.
1) Is there any way by which we can decipher in the server program
weather it is TCP/UDP request so that it can be handled accordingly.
2) Since the server should handle both TCP, UDP requests, I think I
need to create two sockets for both TCP and UDP in the server program?
If yes, is it possible to reuse same port and IP address for two
different sockets??

Please suggest me the best way to implement it.

Thanks in advance
Ravindra. B

On Jan 7, 5:14*pm, Maxwell Lol <nos...@com.invalid> wrote:
> "Ravindra.B" <ravindra.bhadramr...@gmail.com> writes:
> > 1) Is there any way by which we can decipher in the server program
> > weather it is TCP/UDP request so that it can be handled accordingly.
>
> You would have different file descriptors for the TCP and UDP connection.
>
> > 2) Since the server should handle both TCP, UDP requests, I think I
> > need to create two sockets for both TCP and UDP in the server program?
>
> Yes.
>
> > If yes, is it possible to reuse same port and IP address for two
> > different sockets??
>
> The two different protocols allows this by design.
>
> > Please suggest me the best way to implement it.
>
> Classically, the TCP server forks a new instance of itself for each
> connection. I don't personally have any experience of a threaded TCP
> server.

Hi Max,

Thanks for the replay. Please find my queries in line.

> > 1) Is there any way by which we can decipher in the server program
> > weather it is TCP/UDP request so that it can be handled accordingly.
>
> You would have different file descriptors for the TCP and UDP connection.
>
>> Ya!! that makes sense and I can divert TCP and UDP traffic to these two different handlers. But I can get this info only after creating two differnt sockets is that right??

> > If yes, is it possible to reuse same port and IP address for two
> > different sockets??
>
> The two different protocols allows this by design.
>
>>Can you through some more light on this?

> > Please suggest me the best way to implement it.
>
> Classically, the TCP server forks a new instance of itself for each
> connection. I don't personally have any experience of a threaded TCP
> server

>>My goal is to implement a concurrent server which can handle multiple clients simultaniously. We can achieve this by either handling each client by new thread or handling it by new process by using fork

On Jan 7, 8:03*pm, Maxwell Lol <nos...@com.invalid> wrote:
> "Ravindra.B" <ravindra.bhadramr...@gmail.com> writes:
> >> > 1) Is there any way by which we can decipher in the server program
> >> > weather it is TCP/UDP request so that it can be handled accordingly.
>
> >> You would have different file descriptors for the TCP and UDP connection.
>
> >>> Ya!! that makes sense and I can divert TCP and UDP traffic to these two different handlers. But I can get this info only after creating two differnt sockets is that right??
>
> Sure. Look into socket programming. The TCP and UDP connections would
> be on separate sockets. You can use something like select() to see if
> any of the sockets have pending data.
>
>> Ya!! That's absolutely correct.
>
> >> > If yes, is it possible to reuse same port and IP address for two
> >> > different sockets??
>
> >> The two different protocols allows this by design.
>
> >>>Can you through some more light on this?
>
> A TCP packet is a different packet type from a UDP packet. *When it comes
> it, the OS examines the packet, and processes it, and delivers it to
> the application.
>
> The OS has no problem keeping these protocols separate.
>
>> To put it in other way TCP, UDP servers both can share same port and IP address?? Is that right??

> >>>My goal is to implement a concurrent server which can handle multiple clients simultaniously. We can achieve this by either handling each client by new thread or handling it by new process by using fork
>
> Well, if you use TCP, then each connection will have a separate state.
> The OS does this for you.
>
> If you use UDP, then you have to retain the state yourself.
>
> That is, when you get a connection to a UDP port, You have to remember the packet, and the source port and address.
>
> When you plan to respond, you have to look at the response, and find
> out which machine and port has to receive the packet.
> In other words, the UDP server has to do the multiplexing itself.
>
> The Stevens book is a good source for writing networking code. But I don't think it has a threaded server.
>
> If you google, you might find some sample code of a threaded TCP server (i.e.http://sourceforge.net/projects/quickserver/)

>>What I understood from the above reply is, I need get the source IP and port no info from the source packet in the case UDP is that correct?? And also, I guess this only required for concurrent UDP server.
>>One more thing, I have gone through the link that you had mentioned.. that seems to be a java implementation and not in C. Any how, thanx for your useful/timely inputs.

On Jan 7, 11:00*pm, "Ravindra.B" <ravindra.bhadramr...@gmail.com>
wrote:

> Ya!! that makes sense and I can divert TCP and UDP traffic to these
> two different handlers. But I can get this info only after creating two
> differnt sockets is that right??

Each TCP connection that you are handling will be its own socket. You
will also have one socket for accepting new TCP connections. You would
also have a single UDP socket.

> Can you through some more light on this?

A TCP port and a UDP port are two completely different things. Using
TCP port 3012 has no effect on UDP port 3012. They are like 112 Main
Street and 112 Jackson Avenue.

> My goal is to implement a concurrent server which can handle multiple clients
> simultaniously. We can achieve this by either handling each client by newthread
> or handling it by new process by using fork

Or by using a pool of threads, which usually provides the highest
performance.

> bove reply is, I need get the source IP and port no info from the source packet in
> the case UDP is that correct?? And also, I guess this only required for concurrent
> UDP server.

It may or may not be required, depending on the protocol you are
implementing on top of UDP. Many UDP protocols support the client
changing its IP address, and so they don't use the source IP of the
UDP datagram to find the state. But you can do it that way if you want
to.

DS

On Jan 9, 7:43*pm, Andrew Gideon <c182driv...@gideon.org> wrote:

> If the work to be done for each message is brief, it might even make
> sense to simply work around a select() call on all open descriptors.

As long as the work doesn't involve disk I/O. You can't stop doing any
work on every connection while you wait for data to be read from disk.

DS