Using TCP, the workflow for sending the data is following:
- open socket()
- write(data1)
- write(data2)
- write ... data n
- close(socket)
But how is it with UDP? Do we keep the socket open? Or do we open the socket every time the data is ready? What is the best practice for that?
- open socket();
- write(data1);
- close(socket);
- open socket();
- write(data2);
- close(socket);
Opening a TCP socket usually means
create a socket structure in operating system
establish a TCP connection (3 way handshake with a peer)
and closing a TCP socket means
TCP connection release
delete socket structure in operating system
Opening a UDP socket does not trigger any network communication and it only creates a socket structure in OS.
Opening a TCP socket is more costly that opening a UDP socket because opening and closing a TCP socket creates a TCP session whereas opening and closing a UDP socket is a local action only.
It is best practice to reuse existing UDP socket for sending/receiving more than one datagram. It is useless to close a UDP socket if it can be reused for later communication. Moreover if the application closed the UDP socket then incoming traffic to port, that was bound to the socket, would be lost.
Yes, it makes sense keep the socket open if you have more to send (or receive).
Related
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.
I'm new to socket programming. I am wondering what is the internet and hardware overhead of create a TCP connection and let it be idle?
For example, There are1000 clients, each creates a tcp connection to a single server and after tcp connection established, at this point what is the internet or hardware overhead?
There is a 3-way TCP handshake that takes place to establish a TCP connection.
After the connection has been established, the only data that flows through the connection is what the applications send and, if enabled, TCP keep-alives (TCP segment with 0 payload).
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.
I'm creating a socket table from a network composed of 2 hosts. They have a p2p connection and they're working with tcp protocol. Do I have to create a welcoming socket in both of the hosts (as they act like servers)? And a receiving socket as well as a sending socket for each host? Or just one for sending/receiving would be ok?
Each host will need a listening socket on which it will accept new connections. It will also need one socket for each inbound TCP connection (returned from the accept call when it accepts an inbound connection) and one for each outbound TCP connection (returned from the socket call before calling connect to make the outbound connection).
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).