why cannot we use process id insted of taking the

Question

why cannot we use process id insted of taking the port we are binding in socket programming. in socket programming we create socket and get a socket descriptor and we bind to a specific port .for multiple connection why are we not using the process id as all the connection are also a process returning the processs id?

Answer 1

It's an interesting idea, but I think it would raise a few problems:

• How would you know what process ID you wanted to connect to?
• What if you wanted to listen on more than one "port" inside the same process? You only have one process ID.
• IPv4 and IPV6 allocate 16 bits for port IDs, but process IDs usually are 32-bit (or bigger) values, so they wouldn't fit
• There are many programs that don't have a networking aspect, and don't want one. Would automatically instantiating a network communications path to them be a potential security problem?
• One trick you can do (especially with UDP multicast or broadcast) is have several programs listen on the same port (via SO_REUSEPORT), so that when anyone sends out a UDP packet to that port, all of the programs receive it. That trick would be difficult or impossible if programs had to use their (unique) process ID numbers as port numbers.

Answer 2

Because TCP has port numbers in the specification but it doesn't have process IDs.

Why would you want to use a processID that you can't control when you can control the port number? How would a process listen on multiple ports?

Answer 3

First, multiple connections can exist per process. Second, socket API is does not depend on any OS process API.