Unix network process
I was wondering how tcp / ip communication is implemented in unix. When you do a socket transfer, is the tcp / level work (building packages, crc, etc.) done in the same execution context as the calling code?
Or, more likely, the message is being sent to some other daemon process responsible for tcp communication? This process then takes the message and does the requested work of copying memory buffers and building packages, etc.? So the calling code resumes execution right away and the tcp work is done in parallel? Is it correct?
Details would be appreciated. Thank!
source to share
the TCP / IP stack is part of your kernel . What happens is that you call a helper method that prepares a kernel trap . This is a special kind of exception that puts the CPU in a more privileged mode ("kernel mode"). Inside the trap, the kernel checks for the exception parameters. One of them is the number of the called function.
When the function is called, it copies the data into the kernel buffer and prepares everything for the data to be processed. It then returns from the trap, the processor restores the registers and its original mode, and execution of your code resumes.
A core thread picks up the data and uses a network driver to send, does all the processing error, etc.
So yes, after copying the required data, your code resumes and the actual data transfer happens in parallel.
Note that this is for TCP packets. TCP does all the error handling and handshaking for you, so you can supply all the data and it will know what to do. If there is a connection problem, you will only notice after a while, as the TCP protocol can handle short network outages on its own. This means that you have already “submitted” some data before you receive the error message. This means that you will only get the error code for the first packet after the Nth call send()
or when you try to close the connection (it close()
will hang until the receiver acknowledges all the packets).
UDP does not buffer. When the call returns, the package is on it. But he "shoots and forgets", so you only know that the driver put him on the wire. If you want to know if he has arrived anywhere, you must find a way to achieve it yourself. The usual approach is for the receiver to send back a UDP Ack packet (which can also get lost).
source to share
No - no parallel execution. It is true that the execution context when you make a system call is not the same as your normal execution context. When you make a system call, for example to send a packet over the network, you have to switch to the kernel context - its own memory map and kernel stack, not the virtual memory you get inside your process.
But there are no daemon processes magically broadcasting your call. The rest of your program's execution should wait for the system call to complete and return any values it returns. This is why you can expect return values to be available immediately upon return from a system call — values such as the number of bytes actually read from the socket or written to a file.
I tried to find a good explanation of how the kernel context jump works. Here's a very interesting one that is even targeting an architecture-specific implementation:
http://www.ibm.com/developerworks/linux/library/l-system-calls/
source to share