A friend of mine mentioned that I could send TLS application data (HTTP messages) in batch fashion inside a one TCP packet instead sending one by one.
I've researched his claim using Google but couldn't find any.
Is this possible? Wouldn't this cause parsing issues for browsers?
HTTP is a request-response protocol, i.e. each request expects a response. The traditional way with HTTP/1 was to first send a request, then wait for the response, then send another request (if HTTP keep-alive is supported and the connection stayed open) and expect the response etc. With this procedure it could not be possible that multiple requests end up in the same packet since one had to wait for the response of the current request before sending the next one. Similar multiple responses could usually not end up in the same packet since there was also a single response outstanding. A special case here is a preliminary response (status code 100) which is followed by the "real" response. These could be sent together.
It is possible with HTTP pipelining to send multiple requests at once and then wait for all the responses to be sent back in the same order as the requests were sent. In this case multiple requests could end up in the same packet and multiple responses too. But the server is actually allowed to close the connection after a response is done. In this case requests might be left unanswered and one might need to resent the requests. But it might actually happen that the server has processed the request but that the connection was closed before sending the response, so replaying should only be done if it does not change the semantics (i.e. idempotent requests).
HTTP/2 then supports parallel sending of requests, i.e. requests can actually be interleaved in each others and same with responses. This way also multiple requests or responses might end up in the same packet.
Apart from that a clarification might be needed: a normal application does not send TCP packets but it sends data. How these data are packetized for transport is up to the kernel and depend for example on MTU. It might be that a single send results in multiple packets. It might also be that multiple send shortly after each other are combined together into a single packet.
Related
I'm a bit new to restful API usage.
suppose that I am sequentially sending out 1000 post requests in python, is it possible that my server could receive these requests out of order? (for example post request 5 is somehow received before post request 4)
If it is not possible for requests to be handled out of order, how do web application frameworks know what order to handle the requests in? is there some sort of timestamp/metadata that indicates priority of the request? For example, does the oldest request HAVE to be fulfilled as soon as possible?
I am curious because I am using the POST api to populate my database and I noticed that my sequentially sent data NEVER has come out of order. I don't want to be dependent on this assumption that sent data will always be consistently in the proper order, so I thought I should ask here
If you are sending requests and wait for a response before sending the next one, then everything will happen in order, guaranteed.
If you are sending many requests in parallel, there's generally no guarantee which will arrive first and get processed first.
It's pretty reasonable to assume that the request that arrives first also gets processed first, and over a local fast network that may usually be the case; but over the internet specific packets can get delayed for lots of reasons. Even wifi might cause one of your requests to have to be resent if it wasn't received well the first time.
tl;dr: the only way you can guarantee order is if you wait for a response before sending the next request.
I am just curious, what is the fundamental reason to have 200 OK responses from a remote end point to be ACKed by the local end point? RFC 3261 states that it is needed for stability purposes but does not go into details. The only reason that comes to my head is the case with call forking. So, if an AOR is registered at multiple end points and these end points respond simultaneously with a 200 OK message, then an ACK will actually indicate which of the remote parties will participate in a peer-to-peer connection. Is there any other reason to end and INVITE hand shake with an ACK?
It's because SIP needs some responses (only INVITE responses in practise) to be reliably transmitted in situations where the underlying transport is unreliable, such as with UDP.
The ACK request is the way for the (UAC User Agent Client) to let the UAS (User Agent Server) know that it received the final response to an INVITE request. Without employing something like the ACK request there would always be the risk that the UAS response would not get through to the UAC and the call would be left sitting in an incorrect state.
The ACK request doesn't have any specific role in call forking. In the case you've described in a call with multiple end points BYE requests will be sent to any call legs that are not required. ACK requests still need to be sent to any UAS that responds irrespective of whether the UAC wants that call leg to proceed or not.
Initially I was looking for an answer to why ACKs to 2xx responses form a separate SIP Transaction, while ACKs to non 2xx responses don't. Google gave me this:
"When the UAC receives 200 OK, the client transaction is destroyed at TL.
This is done because, the TL is unaware of the above core. The above
core can be a Proxy or an UAC core.
In case of proxy, the 200 OK is forwarded whereas in case of UAC, an
ACK is generated. Now this ACK has to
create a new transaction (transaction created by INVITE had been
destroyed)at TL for its transmission, hence the ACK for 200 OK is
outside the INVITE transaction.
For other non-2xx final responses, the client transaction at TL is not
destroyed and the ACK is generated by TL.
Hence in this case, the ACK is within the transaction."
http://sipforum.org/pipermail/discussion/2011-June/008499.html
Now my next question was why is the client transaction destroyed at TL upon reception of 200 Ok. Is it because ACKs are sent directly to UAS without passing intermediate proxies? (so proxies will never know if the INVITE transaction is actually completed).
Another possibly related issue I am having is that I don't understand why retransmission of 200 OK is done end-by-end. Is there a reason why retransmission is not done in hop-by-hop manner?
The philosophical answer as to why SIP uses different ACK mechanisms is to discreetly torture anyone foolish enough to dig into the bowels of the SIP standard.
Why is 200 OK retransmission handled by UAS?
The answer is detailed in the SIP RFC Chapter 17 Transactions (which is also referenced in the sipforum link your provided).
The reason for this separation is rooted in the importance of
delivering all 200 (OK) responses to an INVITE to the UAC. To deliver
them all to the UAC, the UAS alone takes responsibility for
retransmitting them (see Section 13.3.1.4), and the UAC alone takes
responsibility for acknowledging them with ACK (see Section
13.2.2.4). Since this ACK is retransmitted only by the UAC, it is effectively considered its own transaction.
Putting it another way the SIP designers were worried about the reliability of 2xx responses being delivered over UDP so they decided sending an ACK request from the client (UAC) to the server (UAS) was a good way to implement retransmissions.
I've never really understood why SIP couldn't just use the same mechanism for 2xx and non-2xx ACK's. It would make the job of implementors easier.
Now my next question was why is the client transaction destroyed at TL upon reception of 200 Ok. Is it because ACKs are sent directly to UAS without passing intermediate proxies?
If the INVITE request traversed a SIP proxy or proxies then it's likely that the ACK request will traverse the same proxies (a 2xx response can change the proxies used in subsequent requests within the same SIP dialog so in theory the ACK could traverse different proxies). So no the ACK request handling at the client (UAC) is not designed to handle requests travelling different SIP routes.
Another possibly related issue I am having is that I don't understand
why retransmission of 200 OK is done end-by-end. Is there a reason why
retransmission is not done in hop-by-hop manner?
Because the SIP standard mandates that the responsibility for INVITE response retransmissions is handled by the UAS. A stateless SIP proxy does not have UAS capabilities, it simply passes any requests or responses it receives through to the next SIP agent.
However just to confuse things, a stateful SIP Proxy or a B2BUA may very well implement UAS functionality and in those cases the retransmission will occur on a hop-by-hop basis although in that case each INVITE transaction is between the UAC and the UAS in the Proxy or B2BUA rather than a UAS in the destination SIP client.
Tried to explain the same in the following link
https://abhishekchattopadhyay.wordpress.com/2010/09/21/why-ack-is-a-separate-transaction-for-invite-with-a-successful-200-ok%C2%A0response%C2%A0/
As such the question "why ack is a separate transaction in case of a 200 OK" is not a question at all. This is already explained in 3261. 200 OK (for that matter any final response) is supposed to end the transaction. And so new request would be a new transaction. no surprises!!
the real and uncomfortable question is why is ACK part of the invite transaction if the response is anything but a 200 OK. Read the above link the reason is put down there.
Thanks.
Why is 200 OK retransmission handled by UAS?
The answer in clear for me in RFC 3261 page 128:
"The handling of this response depends on whether the TU is a proxy
core or a UAC core. A UAC core will handle generation of the ACK for
this response, while a proxy core will always forward the 200 (OK)
upstream. The differing treatment of 200 (OK) between proxy and UAC
is the reason that handling of it does not take place in the
transaction layer."
I also think this question for a while and it's clear for me when I think about proxy in the communication path. As we know, non-2xx response take place in the transaction layer. The transaction layer on proxy will response a ACK for the non-2xx response. Also the transaction layer will resend ACK when receive non-2xx again.
Let's suppose, if 200 OK take place in the transaction layer. The proxy transaction layer will response a ACK. The session will be created on UAS. This is no problem if 200 OK can reach to UAC finally. But, that's not the result we wanted as 200 OK may not reach UAC for some other reason.
I have a client application that repeatedly sends commands over a socket connection to a server and receives corresponding responses. This socket connection has a send/recv timeout set.
If the server is slow to respond for some reason, the client receives EAGAIN. On a timeout, I want the client to ignore that response and proceed with sending the next request.
However, currently when I ignore EAGAIN and send the next request, I receive the response from a previous request.
What is the best way to ignore/discard the response on an EAGAIN?
You can't. You have to read it. There is no mechanism to ignore bytes in a TCP byte stream.
EAGAIN may indicate a timeout elapsed (you also need to handle EWOULDBLOCK as well). If you are using TCP, you must read pending data before you can read any subsequent data. If you get an EAGAIN on a read, you have to perform the same read again, using the same parameters. Just because the server is slow to respond (or the network is slow to deliver the response) does not mean the response will not arrive at all, unless the connection is closed/lost.
If you really want to be able to receive responses out of order, you need to design your communication protocol to support that in the first place. Give each request a unique ID that is echoed in its response. Send the request but do not wait for the response to arrive. That will allow the client to have multiple requests in flight at a time, and allow the server to send back responses in any order. The client will have to read each response as it arrives (which means you have to do the reading asynchronously, typically using a separate thread or some other parallel signaling mechanism) and match up each response's ID to its original request so you know how to then process it.
i am receiving multiple 2** responses for a call. The problem is that once the call is connected and the server receives the "ACK" packet and the call starts successsfully, server again sends the "OK" response packet back to the callee and recieves the "ACK" packet again for it. This happens multiple times before the call gets terminated automatically. Can somebody explain to me why this is happening that my server is sending the "OK" response even after the call is connected successfully and what can be the possible solution for the problem? Thanks in advance for any help.
A SIP UAS will retransmit the 2xx response multiple times until it receives the ACK request from the UAC. See the SIP RFC chapter "13.3 UAS Processing" for the gory details.
Most often this sort of problem happens when the ACK sent by the UAC is invalid and thus prevents the UAS from matching it to the INVITE transaction. ACK requests have special rules about their construction see 13.2.2.4 2xx Responses. To make things even more difficult the construction of the ACK request differs for 2xx and non-2xx final responses.