title: POSIX sockets: Accepting connections with different transport protocols?
body: <p>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.</p>
  
  <p>Of course, a straghtforward approach would be to have N independent server sockets (each created via a call to <code>socket()</code> with the appropriate <code>protocol</code> 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).</p>
  
  <p>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?</p>
  
  <p>(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).)</p>
  
  <p>EDIT: I'm not interested in N (client) connections whose file descriptors are returned by N calls to <code>accept</code>. 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).</p>