I'm having some trouble understanding some key concept of the computer networking.
A UDP server usually only needs one socket, whereas a basic TCP server
needs two sockets. Why is that?
If a TCP server were to support n simultaneous
connections, each from a di erent client host, how many sockets would the
TCP server need?
If you can help me understand it I will be more than happy!
Thanks in advance.
hello i’ll try to explain this in a simple manner
TCP is a connection oriented protocol, while UDP is not.
what’s the difference?
In TCP it client and server must be connected first before sending and receiving msgs.
In UDP it can send and receive msgs without securing connection between client and server.
In terms of sockets (basic Tx and Rx)
UDP:
Client - 1 socket for Rx and Tx
Server - 1 socket for Rx and Tx
TCP
Client - 1 socket for Rx and Tx
Socket - 1 socket (main socket) and possibly n sockets
n - depends on how many clients will connect to the server
Related
I have an application that sends simple data over TCP (simple, no auth) and another application that must receive it. The only allowed connection between the two is UDP.
On the receiving side, I have SOCAT listening for incoming UDP packets and forwarding them via a TCP connection to the computer that hosts the software.
socat UDP4-LISTEN:5000, fork TCP-CONNECT:192.168.1.5:5001
On the sending side, I can send test data via
socat UDP4-connect 192.168.1.1:5000
There is a firewall in the way and I have no control over it which is why UDP is my only option. The firewall allows UDP out from the sender and UDP in to the receiver.
What I don't know is how to take a TCP connection on the sender and forward its output via UDP. And I don't know if this is the best way or if it will work at all.
Thank you
As socks5 rfc says,
A UDP association terminates when the TCP connection
that the UDP ASSOCIATE request arrived on terminates.
I wonder, doesn't "the TCP connection that the UDP ASSOCIATE request arrived on" just terminate when it timeouts? As there is no more data need to be sent in that TCP connection.
Should the client send meaningless data in that TCP connection just to keep it alive while it need the UDP association?
I wonder, doesn't "the TCP connection that the UDP ASSOCIATE request arrived on" just terminate when it timeouts?
No. The TCP connection is kept alive as a signal that the proxied UDP socket is still valid. Without it the client has no way of knowing whether the server is still reachable or whether the UDP socket is still allocated.
Similarly, without the TCP connection the server has no other way of knowing whether the client is still connected.
Should the client send meaningless data in that TCP connection just to keep it alive while it need the UDP association?
There's no need to send meaningless data. Just keep the connection alive. TCP has a built-in keepalive mechanism which can be turned on.
Edit: It's worth pointing out that the default TCP keepalive times on both Linux and Windows is fairly long. See this question on ways of tweaking it for specific sockets.
Hi guys I'm currently developing a C project in which we basically need to connect N clients to a server through a proxy. I'm doing the first connecting using the TCP protocol. After this, the client may request a file download using UDP. Do I need to have another socket listening to another port and connect the client again to this port or is this an incorrect way of thinking?
TCP and UDP communicate in very different ways. You'll need a separate socket for each
one.
You'll probably want to use the TCP socket to communicate the UDP port to use.
Please assume that we can distinguish packets of different TCP connections from each other, if so then can we accept multiple TCP connections on the only one socket in server side? I know that the server binds on a socket and when accepting new connection assigns a new socket to new connection. Would I override ACCEPT systemcall?
Please assume that we can distinguish packets of different TCP connections from each other
You can't assume it. There are no 'packets' visible to the application over a TCP connection. A TCP connection provides a byte stream. You can't guarantee that the next thing you read will be say a message header telling you which client the message is from.
First of all, is there any problem with using both UDP and TCP on the same server?
Secondly, can I use the same port number?
Yes, you can use the same port number for both TCP and UDP. Many protocols already do this, for example DNS works on udp/53 and tcp/53.
Technically the port pools for each protocol are completely independent, but for higher level protocols that can use either TCP or UDP it's convention that they default to the same port number.
When writing your server, bear in mind that the sequence of events for a TCP socket is much harder than for a UDP socket, since as well as the normal socket and bind calls you also have to listen and accept.
Furthermore that accept call will return a new socket and it's that socket that you'll then have to also poll for receive events. Your server should be prepared to continue accepting connections on the original socket whilst simultaneously servicing multiple clients each of which will be triggering receive events on their own sockets.
Firstly,there is no problem using both tcp and udp on the server.
Secondly,we can have both UDP and TCP requests on same port ,because each request is identified by a quintuple contained by source IP ,Destination IP, Source Port, Destination Port, PROTOCOL(as protocol can be TCP or UDP).