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).
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.
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).
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.
In this introduction article: http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/overview.html
It states that reasons for TCP keep alive are:
Preventing disconnection due to network inactivity
Detect dead peers
So in my application, there is a busy TCP socket. Packets are frequently sent back and forth between the two peers - so there is a good amount of packets with ACK flag set.
The application protocol uses other means for dead peer detection.
Is TCP keepalive still necessary for the case above?
No. TCP keepalive is practically a 0 byte-long tcp packet. If you can be sure on your app protocol, it is unneeded.
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).