In a computer network, are the port address (at the transport layer) and the operating system process ID the same or different?
If they are different, how are they different?
No they both are different. The port addresses are used to identify a particular service that is running on a machine. It's basically well known to both sender and receiver. And most importantly they are reserved. A port number is used by a packet to identify to which process it should be delivered. Whereas a process id is a random number that is assigned to a process by the operating system.
If port number would have been randomly assigned then the communicating parties would not be able to communicate properly. As every node would choose a port number depending on its choice.
Simply speaking your port number is something that is used to identify a particular service on a computer globally. And the process id is used to identify a process uniquely on your computer.
Different! Port number for a particular process is fixed whereas, the process ID is assigned by the CPU when the program starts and it always changes whenever the process is restarted.
Port addresses are well known and fixed for example http uses 80 as port number.
whereas process id is created by the cpu when it is loaded in the main memory. they are completely different.
Related
I started reading UNIX network programming by W. Richard Stevens and I am very confused between a port and a socket . when I read on internet it said that socket is an endpoint for a connection and for port number it was written that , IP address and port no form a unique pair .
So now my question is that :
(1) What is the difference between these two ?
(2)How are sockets and ports internally manipulated. Are sockets a file ?
(3) How is data sent when we send it using an application ?
(4) If sockets are there then why do we use port numbers ?
Sorry for my English.. Thanks in advance for the reply.
(1) What is the difference between these two ?
A computer running IP networking always has a fixed number of ports -- 65535 TCP ports and 65535 UDP ports. A network packet's header contains a 16-bit unsigned-short field in it specifying which of those ports the packet should be delivered to.
Sockets, on the other hand, are demand-allocated by each program. A socket serves as a handle/interface between the program and the OS's networking stack, and is used to build and specify a context for a particular networking task. A socket may or may not be bound to a port, and it's also possible (and common) to have more than one socket bound to a particular port at the same time.
(2)How are sockets and ports internally manipulated. Are sockets a
file ?
That's totally up to the OS; and different OS's do it different ways. It's unclear what you mean by "a file" in this question, but in general sockets do not have anything to do with the filesystem. On the other hand, one feature of Unix-style OS's is that socket descriptors are also usable in the much same way that filesystem file descriptors are -- i.e. you can pass them to read()/write()/select(), etc and get useful results. Other OS's, such as Windows, do not support that feature and for them you must use a completely separate set of function calls for sockets vs files.
(3) How is data sent when we send it using an application ?
The application calls the send() function (or a similar function such as sendto()), passes in the relevant socket descriptor along with a pointer to the data it wants to send, and then it is up to the network stack to copy that data into a packet and deliver it to the appropriate networking device for transmission.
(4) If sockets are there then why do we use port numbers ?
Because you need a way to communicate with particular programs on other computers, and computer A has no way of knowing what sockets are present (if any) on computer B. But port numbers are fixed, so it is possible for programmers to use them as a rendezvous point for communication -- for example, your web browser knows that a web server is almost certain to be listening for incoming HTTP requests on port 80 whenever the server is running, so it can send its requests to port 80 with a reasonable expectation of getting a useful response back. If it had to specify a socket as a target instead, what would it specify? The server's socket numbers are arbitrary and likely to be different every time the server runs.
1) What is the difference between these two ?
(2)How are sockets and ports internally manipulated. Are sockets a file ?
A socket is (IP+Port):
A socket is like a telephone (i.e. end to end device for communication)
IP is like your telephone number (i.e. address of your socket)
Port is like the person you want to talk to (i.e. the service you want to order from that address)
A socket is part of a process. A process in linux is a file.
(3) How is data sent when we send it using an application ?
Data is sent by converting it to bytes. There is little/big endian problem regarding the ordering in bytes so you have to take this into consideration when coding.
(4) If sockets are there then why do we use port numbers ?
A socket is (address + port) that means the person you want to talk to (port) can be reachable from many telephone numbers (IPs) and thus from many sockets (that does not mean that the person on one telephone number will reply to you the same as the one in the other telephone number because his job here/there may be different).
I have a process A that needs to send a message to all process of type B that are running. The process A doesn't know about these other processes, they can be created and destroyed depending on external factors, thus I can have a varying number of process of type B running.
I thought I could use an UDP socket in the process A to send messages to a port P and have all my processes of type B to listen to this port P and receive the a copy of the message.
Is that possible?
I am working with Linux OpenWRT.
I am trying with LuaSockets, but I am getting a "address already in use" error. It seems that I can not have multiples applications to listen to the same port ?
Thanks for your help
It could be useful to use shared memory if all the processes are local to a single machine.
Have a look at http://man7.org/linux/man-pages/man7/shm_overview.7.html for an explanation.
In short you will need the master process to create a shared memory region and write the data into it. The slave processes can then check the data in the memory region and if it has been changed act upon it. This is however just one of many ways to accomplish this problem. You could also look into using pipes and tee.
When a packet is routed to the destination, it uses a port number to map it to and appropriate process at the server. However, I do not find any documentation on how the mapping of (port- process) is done. Please let me know with some interesting links/references. Thanks.
The operating knows which process has which ports open, that's about it in general terms. A specific answer would require specifying a specific operating system, but you can guess that there is something like a port control block for each port and that it probably contains the PID of the process that owns it, or a pointer to its process control block, etc.
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?
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.
First, multiple connections can exist per process. Second, socket API is does not depend on any OS process API.
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?
When a server accepts a client over a tcp/ip connection, a new socket is created.
Is it safe to use the LocalEndPoint port (from the client perspective) as an id?
Example (from the server perspective):
int clientId = ((IPEndPoint)client.RemoteEndPoint).Port;
On my local machine, the port seems to be unique, but with multiple clients on different machines, it may not always be the case.
My second question:
Let's say the port can't be used like a unique id, how the server (and hence the protocol stack) can differentiate between two client socket (from the server perspective).
TY.
The uniqueness of a socket is identified by 4 values: (local IP, local port,remote IP, remote port) and that's how the protocol stacks identify a connection.
Given this, you can have several connections from the same port number to same port number but e.g. to a different remote address. Typically you have to specifically request
permissions to use the same local port for more than 1 outbound connection.
Your example int clientId = ((IPEndPoint)client.RemoteEndPoint).Port; doesn't use the local port, but the port on the remote end. This is certainly not unique, as different clients might happen to chose the same port. Your server port is probably fixed, and will always be the same for all connections. Thus if you want something unique on the server side, you have to use the 4 values mentioned above.
However if you only need a unique identifier within your own client application among connections you've set up yourself, the local port will do.
Don't use the remote end point - create a GUID - for each (accepted)connection.
Pass the GUID back to the client socket - get the client to save it (much better than a HTTP session) and add the GUID to any subsequent HTTP headers directed at you :)
then!! the perfect need for a HastTable<> !!! only a couple of situations I know of!
Why not just use "client" as the unique identifier. A unique identifier need not be of a value type.
The short answer to the first question is probably no. The client OS will usually pick a port from a range. Even if that range is 40-50 thousand large, if your server is busy enough, sooner or later you may have the same port coming in from different clients. If it isn't a busy server you may get lucky.
Sockets are differentiated from each other based on pairs of address/port/protocol. The combined set of these values from the client and server will be unique.
Why can't you just use the client address and port as a temporary id?