I'm wondering what is the minimum required overhead in terms of the number of listening ports / server sockets required for accepting say N different connections, each using a different transport protocol that runs on top of IP, e.g. TCP, SCTP, DCCP, UDP etc.
Of course, a straghtforward approach would be to have N independent server sockets (each created via a call to socket()
with the appropriate protocol
parameter), each listening on a unique port. However, implementing this approach in an application that uses multiple protocols simultaneously would be extremely inconvenient since a client would need to know multiple server ports. In addition, in a peer-to-peer application that peers only once for each protocol (with the same client), the fact that each of the N server sockets only accepts a single (client) connection looks like a huge overhead (N additional sockets are introduced purely for handling N "real" connections to a single peering client).
Is it possible to do better than that, e.g. by reducing the number of listening server sockets and/or listening on the same port?
(For simplicity, you can assume N=2, one connection is TCP and the other one is DCCP or UDP (please don't make assumptions on connectionless communication since DCCP is connection-oriented).)
EDIT: I'm not interested in N (client) connections whose file descriptors are returned by N calls to accept
. The question is about the additional overhead to make those N connections possible (i.e. there has to be at least one additional server socket that listens for incoming connections).
To sum up what's said in the comments above: Since in the
call we must specify the
protocol
, we cannot use one socket for multiple protocols. We also cannot portably writesee SOCK_RAW Demystified.
Regarding using the same port with different sockets: the possibility for this varies by system; e. g. see HP-UX (
man 7f inet
):vs. Linux (
man ip
):