Re: Multi-Threaded server which can handle UDP, TCP clients

On Jan 7, 8:03 pm, Maxwell Lol <nos...@xxxxxxxxxxx> wrote:
"Ravindra.B" <ravindra.bhadramr...@xxxxxxxxx> 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.


.

Relevant Pages

  • Re: Incoherent E-mails
    ... The Novell crap was originally run on IPX ... The term in the early-mid nineties was "packet storm". ... The original advantage of UDP was ... > 60 bytes for TCP. ...
    (alt.computer.security)
  • Re[2]: Why TCP is more secure than UDP?
    ... The point that you use TCP ur UDP doesnt really matter, ... Suppose this service just echoes back any packet I send it. ... BD> Suppose my tricky friend "Moe" is across the internet at 10.0.0.1 (Oh ...
    (Security-Basics)
  • Re: recvfrom() strange operation
    ... I have only one escape way for this kind of UDP operation. ... TCP receive you always send data to upper level in sequence, ... In case of UDP you do not know the packet ...
    (comp.os.linux.development.system)
  • Re: A question regarding MTU: how it can effect TCP performance + other queries
    ... Can you check if your physical NIC has TCP large send offload enabled? ... I can't think of anything for the UDP case however, that just seems strange to me. ... Are you grouping multiple UDP packets in one TCP packet? ... encapsulated within another TCP packet when passed to physical interface, while for UDP I am sending UDP packet encapsulated within TCP packet when passed to physical interface. ...
    (microsoft.public.development.device.drivers)
  • Re: HTTP over both TCP and UDP
    ... but we're not talking about using UDP. ... with TCP packets. ... routers, and the server. ... you put a sequence number in the UDP packet. ...
    (comp.os.linux.networking)