is is possible to bind TCP socket to many ports? - sockets

I see that some applications using TCP can be configured to bind to multiple ports. Does this mean that they open multiple TCP sockets, or it is possible to open a single socket and bind it to many local ports?
Thanks.

A TCP socket can only be bound to a single port. In particular, if you try to bind an already-bound TCP socket to a second port, bind() will return -1 and set errno to EINVAL.
Servers that accept incoming TCP connections on multiple ports are doing it by creating multiple TCP sockets.

Related

can a socket with the same local address be in two states at once 'LISTEN' and 'ESTABLISHED'

I have a question about sockets where a socket gets in to a peculiar situation, it is both Listening and Established. I must add that I am working with SSL sockets. It is possible that the TLS handshake timed out and some how this got in to this state?
netstat output
tcp 0 0 XX.XX.xx.83.9999 XX.XX.xx.10.42146 ESTABLISHED --> socket in established state
tcp 0 0 XX.XX.xx.83.9999 . LISTEN -> socket is also in listen state.
how can be it in both LISTEN/ESTAB
A single socket cannot both listen and be established. And this is not what you are seeing.
These are two separate sockets, not the same socket. Both sockets are bound to the same local IP and port. But one is connected to a peer (i.e. connection established) while the other is listening for new connections.

Handling multiple TCP connections on the only one socket in server

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.

p2p sockets table

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).

TCP and UDP same ports, different process

I know you can't have two different process using the same port, but what happens if one is using tcp and the other one udp? Can you have two different process each one binding a socket to the same port but different protocol?
The 5-tuple (protocol, source ip, source port, dest ip, dest port) must be unique. That means that not only can you have TCP and UDP using the same port number, but even outgoing connections with the same protocol and local port number, but different destinations.
When listening however, sockets usually must be unique in their protocol, i.e. you can/should not open another TCP socket with the same port number.
TCP ports and UDP ports are not related to each other at all.
Yes. Two sockets can bind same port number but different protocol.
It's not the same port, just happens to have the same number.

Can TCP and UDP sockets use the same port?

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).