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
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
I am writing a UDP based client server and have got pretty much the code, but I am confused about how UDP server sends the response back to UDP client, this is my understanding till now:
Suppose a UDP client wants to communicate with a UDP server, so it will send a request to the UDP server (using the UDP socket opened at client's end), now this will reach the UDP module at the UDP server, where UDP module will identify the UDP service using the port number and will send that request to that UDP service/server.
Now, since UDP is a connection-less protocol so unlike TCP, UDP server will not send response over some connection, instead, UDP server will extract the source IP address and source port from the request and send the response back to client.
My confusion is that at server side, there is a socket which is bound to a UDP port and "continuously" listening for any UDP client request, but this is not true at client side, UDP client will open a socket to send the request to UDP server and then that's it, I think it cannot keep that port hanging for UDP server to respond, and if that port closes then how client will receive the response back.
I mean ofcourse, UDP server's response will reach back the UDP client because IP address is there, but once that response has reached UDP module of the client, even though there will be a port but how UDP module can send it to the client who originally sent the request because it would have closed the socket bound to that port? Or it will not?
I am looking for answer which clearly describes the UDP communication (I am not interested in contrasting it with TCP or explaining TCP since I have already fair understanding of TCP), especially how the response will reach back the UDP client.
My confusion is that at server side, there is a socket which is bound to a UDP port and "continuously" listening for any UDP client request, but this is not true at client side, UDP client will open a socket to send the request to UDP server and then that's it, I think it cannot keep that port hanging for UDP server to respond, and if that port closes then how client will receive the response back.
I agree. This is your confusion. Why do you think can't keep the socket open and do a receive on it? It can.
I mean ofcourse, UDP server's response will reach back the UDP client because IP address is there, but once that response has reached UDP module of the client, even though there will be a port but how UDP module can send it to the client who originally sent the request because it would have closed the socket bound to that port?
Why?
Or it will not?
Not.
The client:
creates a socket
sends a datagram
calls recvfrom() or friends to receive the response.
Of course if the client isn't interested in the response it can close the socket, but this is not the normal case.
I am looking for answer which clearly describes the UDP communication (I am not interested in contrasting it with TCP or explaining TCP since I have already fair understanding of TCP), especially how the response will reach back the UDP client.
So don't tag your question with the tcp tag.
Yes, UDP server can send back to client. Here is an example:
https://www.cs.rutgers.edu/~pxk/417/notes/sockets/udp.html and code demo https://www.cs.rutgers.edu/~pxk/417/notes/sockets/demo-udp-04.html
We now have a client sending a message to a server. What if the server wants to send a message back to that client? There is no connection so the server cannot just write the response back. Fortunately, the recvfrom call gave us the address of the server. It was placed in remaddr:
recvlen = recvfrom(s, buf, BUFSIZE, 0, (struct sockaddr *)&remaddr, &addrlen);
The server can use that address in sendto and send a message back to the recipient's address.
sendto(s, buf, strlen(buf), 0, (struct sockaddr *)&remaddr, addrlen)
The client uses some random but unique source port. The server sends the response back to this unique port. Server will never receive 2 request at a time from single port. Server uses this fact to map response to request. Only after receiving the response, client closes this source port/ socket. The client can send as much request as the count of ports available for its disposal at any given point of time. Since the port is closed as soon as the response is received, it becomes available again.
Reference: https://www.slashroot.in/how-does-udp-work
This question is a (sort of) follow-up to Intercepting/Rerouting TCP SYN packets to C++ program in linux.
The question is: If SYN or any other TCP packet is modified (say the source IP address/port is changed) before it is sent to the network (i.e. on the source), what effect will it have on TCP reliability (for example if the packet is lost)?
The effect will be exactly the same as for not modified packet - the network stack will timeout and re-try, and eventually give up, and return with ETIMEDOUT from connect(2).
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).