I know a lot about sockets, but in the os class the professor never told us all the details and I can't find them by googling them.

I believe it's because I don't know exactly what information does a network package carries as overhead except for the IP of the receiver.

Ok, let's say computer 1 has a program A which creates a binding socket at port 80. Now computer 2 has a program B which creates a regular socket that sends a connection request at computer 1. This request contains the following extras:
1) The binding port number 80.
2) The IP address of the receiver (computer 1)
3) The IP address of the sender-itself (computer 2)
?) Should I put information saying this is a connection request?
?) Should I put something which says, next time you send me a request
this is the socket which I must use to inject this package.

Computer 1 receives that request, somehow knows that this is a connection request and probably uses the port number which was extracted from the package and this is how it knows that this package needs to be injected to the binding socket 80 that program A created, correct?

Now, program A creates a new regular socket to be used for the connection.

program B's regular socket does not know anything yet about program A's newly created regular socket.

Now let's assume program A's newly created regular socket sends that information to program B's regular socket. When this package reaches Cumputer 2 how does the OS know that this package needs to be injected to the program B's regular socket?

And after that, when program B replies through it's regular socket when that package reaches computer 1 how does the OS knows that this information needs to be injected through program's A new regular socket?

Do packages carry a PID or something? But still, this is not enough because a process can have multiple regular sockets. Plus regular sockets can have the same port number, so the port is useless. Only binding sockets have unique port numbers that can be used to identify which socket to be used to inject the package.

So, what exactly happens behind the scene? Does anyone know?

Thank you!

inject is not the right word here. The ports are always connected directly to the program which handles it. Either by reading or writing into it. As far as I know the kernel knows which port is used by which app. You can use netstat (for example) to see it.
The communication (sockets) are represented by file descriptors, so the application will read and write actually file descriptors.
The file descriptor points to a communication channel which itself knows the local/remote port and ip address information (among others). Also it knows if the packages is a reply or a request and can handle the real data to be sent/received. But it depends on the type of the channel.

Here you can find some basic details of the tcp protocol
https://en.wikipedia.org/wiki/Transm...ntrol_Protocol
and another one about udp: https://en.wikipedia.org/wiki/User_Datagram_Protocol

1 members found this post helpful.

I've always found this to be good reading, https://beej.us/guide/bgnet/

To be honest, your questions are a bit off because you make a correct statement about a binding, and then you ask how the system knows what to do when traffic comes in on a port that it's listening on.

In the code, the network port knows the receive function to call for traffic on a given port, because that's how it was set up. This is dynamic, but also there is a default if there wasn't something set up for the port.

I'd actually suggest asking this one on one with your instructor because the two of you can look at actual sample code and discuss at the same time.

Thank you both for the references!


There have been 3 years since I had this class. Now I have graduated

Neither is "Package". It's "Packet".

Anyway, you might want to buy a copy of "Linux Networking Internals" if you're curious about how the TCP protocol (that's the layer that routes data to ports and therefore sockets) is implemented in the kernel.

I just did a quick google and I didn't really find any good free alternatives.

2 members found this post helpful.

Well I recommend you search for source examples of TCP and UDP client-server. There are plenty.

Read the manual pages for the system calls used, and also refer to the See Also sections in those man pages.

You say you know a lot about sockets. Great! Expand that knowledge with study, I've given you a great reference, that used to be the defacto guide. May still be. Either case, using Linux and gcc, you have all you need to be able to compile example code, and also create your own test code.

1 members found this post helpful.

These might or might not be helpful:

https://ops.tips/blog/how-linux-creates-sockets/

https://www.linuxjournal.com/article/7660

https://linux-kernel-labs.github.io/...etworking.html

https://viveksubbarao.wordpress.com/...ns-internally/

Also, as the professor doesn't seem to be using the same words as everyone else (for one thing, "regular" isn't a technical description of a type of socket), I might suggest that actually writing some working sample programs would be a good first step towards understanding more.

1 members found this post helpful.

If we're talking about TCP? Generally speaking, that's not true...

The host and port at the other end of socket connection are indeed set when you connect, and stored in the kernel. You can see it with ss.

As well as the beej guide mentioned above, the books mentioned here are classics https://en.wikipedia.org/wiki/TCP/IP_Illustrated & he wrote a quite a few other good ones.

1 members found this post helpful.