Who implements the 3way handshake process (syn - syn+ack - ack) , the operating system (kernel) auto, the developer of the app ?
In the web server <--> web browser environment , was apache programmed to send a SYN+ACK pachet upon the arrival or the SYN packet ? I can;t figure it out , because I know how to send a raw packet with scapy but i don;t know who manages this ...
Thanks
Who implements the 3way handshake process (syn - syn+ack - ack) , the
operating system (kernel) auto, the developer of the app ?
Not the app of course.It is done but the implemenetation of TCP/IP stack part of your OS
In the web server <--> web browser environment , was apache programmed
to send a SYN+ACK pachet upon the arrival or the SYN packet ?
Application servers use underlying OS facilities for the network communication. The part you describe is completely done by the TCP/IP implementation of the OS
I know how to send a raw packet
Yes but when sending a raw packet you can only "form" the data in the frame which usually are not "visible"/accesible. You don't define a flow or have any other control.
Related
I am an embedded software developer who has any experience with TCPIP on connected devices. Also, I am not a software protocol expert, so I am a bit confusing about TCPIP protocol stack + responsiblities of its various phy layers.
First of all, I have experiences with such protocols like UART, SPI, CAN, USB... As you know, the phy layer directly affects you while selecting the protocol you used at the software level. For example, if you use usb and you build a software protocol on it, you do not occasionally deal with some details like checking corrupted frame in your sofware protocol, because phy layer of it guarantees this operation. CAN also has some CAN Controller facilities like crc and bit stuffing so, it is really reliable. But the situation is not the same for simple peripherals like UART/USART. Let's say you are using a bluetooth module to upgrade your firmware, you need to be aware of almost everything that can occur while communicating like delays, corrupted frames, payload validating etc.
Briefly, i am trying to understand the exact role of newtork interfaces come included in MCUs, that are interfaced with RJ45 phy sockets directly. In another words, imagine that I wrote a server application on my pc. Also i configured and ran an application in my development board which has an RJ45 socket and it runs as a client. Also imagine they established a connection over TCP. So, what will be the situation at the client side, when i send a 32 bytes of data to the socket from the server side? What will I see at the lowest level of MCU that is an RxCompleteInterrupt()? Are the data I sent and some other stuffs appended to the TCP packet guaranteed to be delivered by the eth controller in the MCU and ethernet controller of my PC? OR am i responsible (or the stack i used) check all the things necessary to validate whether the frame is valid or not?
I tried to be as clear as it would be. Please if you have experience, then try to write clean comments. I am not a TCPIP expert, maybe I used some wrong terminology, please focus the main concept of the question.
Thanks folks.
If you don't have any prior experience with the TCP/IP protocol suite, I would strongly suggest you to have a look at this IBM Redbook, more specifically at chapters 2, 3 and 4.
This being said:
So, what will be the situation at the client side, when i send a 32
bytes of data to the socket from the server side? What will I see at
the lowest level of MCU that is an RxCompleteInterrupt()?
You should have received an Ethernet frame in your buffer. This Ethernet frame should contain an IP packet. This IP packet should contain a TCP packet, which payload should consist in your 32 bytes of data. But there will be several exchanges between the client and the server prior to your data to be received, because of TCP being a connection-oriented protocol, i.e. several Ethernet frames will be sent/received.
Are the data I sent and some other stuffs appended to the TCP packet
guaranteed to be delivered by the eth controller in the MCU and
ethernet controller of my PC? OR am i responsible (or the stack i
used) check all the things necessary to validate whether the frame
is valid or not?
The TCP packet will ultimately be delivered, but there there are not warranties that your Ethernet frames and IP packets will be delivered, and will arrive in the right order. This is precisely the job of TCP, as a connection-oriented protocol, than to do what is needed so that the data you are sending as a TCP payload will ultimately be delivered. Your MCU hardware should be the one responsible for validating the Ethernet frames, but the TCP/IP stack running on the MCU is responsible for validating IP and TCP packets and the proper delivery of the data being sent/received over TCP.
You can experiment with TCP on a Linux PC using netcat, and capture the exchange using Wireshark or tcpdump.
Create a 'response' file containing 32 bytes:
echo 0123456789ABCDEFGHIJKL > response.txt
Start Wireshark, and filter on lo interface using filter tcp port 1234
Start a TCP server listening on TCP port 1234, which will send the content of response.txt upon receiving a connection from the client:
netcat -l 1234 < response.txt
In another console/shell, connect to the server listening on tcp/1234, and display what was received:
netcat localhost 1234
0123456789ABCDEFGHIJKL
On Wireshark, you should see the following Wireshark Network Capture, and be able to expand all frames/packets of the full exchange using the IBM Redbook as a reference.
Your 32 bytes of data will be in the payload section of a TCP packet sent by the server.
I have a strange problem here. I am writing a small server application in C++ on a Raspberry, and a commercial program running on Android is meant to connect to it. The data exchanged are very small packages for position control of a technical device. My program works fine, I set up a standard TCP/IP socket, bind it to an address, start listening and when a SYN signal comes from the client, i accept it. Then the client sends request, I send answers, and all potential error messages and socket errors are of course monitored. The communication from client to server looks like this with other programs using the same protocol (and everything works fine):
Client > SYN
SYN ACK < Server
Client > ACK
Client PSH ACK ... some request ...
ACK < Server
PSH ACK ... some reply ... < Server
and so on. This works fine with other programs using the same protocol, but not with the one on an Android 7 tablet. The reason is that the Client on the tablet sends FIN, ACK followed by SYN immediately when receiving the first reply from the server. The client has received the reply and processed it happily without any error - there is no obvious reason for the FIN! That might be a bug, but I do not have access to the client code. Is there a workaround to handle this aside from calling "accept" again after each write from the server???? Many thanks in advance ...
A newbie question: who exact send the ACK, the transport layer or the app? I have a COM-server with particle counters to send the data to my app. Sometimes I have a lost data. When I check the Wireshark protocol I see that the packets were sent from COM-Server but failed ACK from receiver. I think that ACK is missing because the my program has the error and can't edit the data properly. My colleague says that the interface (socket) simply gets no data and can't return ACK. Who is right?
TCP is a transport layer protocol. The ACK is part of TCP. Thus the ACK is part of the transport layer and send there.
Note that there might be apps which include the transport layer (i.e user space TCP implementations) in which case the ACK is send by the app, but not in the application layer but still in the transport layer. But in most cases TCP is implemented in the kernel and is thus outside the app. See OSI or TCP/IP model for more information about these layers.
My colleague says that the interface (socket) simply gets no data and can't return ACK. Who is right?
Assuming that you are not using a user space TCP implementation: The OS kernel will ACK the data as soon as these data are put into the socket buffer of your application. It will not ACK the packet if it failed to put it into the socket buffer, i.e. if the socket buffer is full because your application failed to read the data. In this case it will also reduce the window so that the peer will not send anymore data.
I have a VERY dumb, slow embedded device which currently sends a tiny, custom TCP message to a TCP socket on a server.
I want to change how the server works, and am looking at a message broker. Can I give RabbitMQ a custom TCP stream definition or some code that handles it, or does it only speak AMQP and I have to go for a different solution (e.g. a tiny socket server written in C that consumes TCP and spits out AMQP).
Thanks!
RabbitMQ only speaks AMQP, so the answer is no.
That said, any data can be transmitted as message payloads in AMQP, so feel free to bridge to your app that way. You'll need an "AMQP->your TCP needs" translation layer though.
My question is that when a socket at the receiver-side sends an ack? At the time the application read the socket data or when the underlying layers get the data and put it in the buffer?
I want this because I want both side applications know whether the other side took the packet or not.
It's up to the operating system TCP stack when this happens, since TCP provides a stream to the application there's no guarenteed 1:1 correlation between the application doing read/writes and the packets sent on the wire and the TCP acks.
If you need to be assured the other side have received/processed your data, you need to build that into your application protocol - e.g. send a reply stating the data was received.
TCP ACKs are meant to acknowledge the TCP packets on the transmission layer not the application layer. Only your application can signal explicitly that it also has processed the data from the buffers.
TCP/IP (and therefor java sockets) will guarantee that you either successfully send the data OR get an error (exception in the case of java) eventually.