The reference for this method only says what happens locally on the client, and says nothing about what it potentially sends to the server. Apparently, our server has some challenges with receiving a lot of status code 499 from us when we cancel a request, but I can't find anything about how URLSession handles cancellation. Is there a standard cancel-message over the protocol HTTP?
The client doesn’t send 499. Status codes are one-way. Rather, the client closes the network connection. The server records that dropped connection as a 499 status code in its logs.
If the server is HTTP/2 or later, the client may send either a END_STREAM or RST_STREAM message to cancel a single request without canceling other requests on the same connection, or it may just drop the connection. Either way, you’ll probably just see a 499 in your logs. There is little reason to care whether the connection was dropped or cancelled.
Related
Is there any configuration like android user-permission in iOS to control access to internet?
I think all new projects access to internet by default, is that correct?
When I send a request to the internet it returns 0 http-error code, it means I can't access to the internet.
yes, it is correct all the new ios project have access to the internet by default.
A status code of 0 in an NSHTTPURLResponse object generally means there was no response and can occur for various reasons. The server will never return a status of 0 as this is not a valid HTTP status code.
Any http request will first be processed by the operating system, and during that phase you can get an error. Getting an error means that your request never got a response from the server (and with the exception of https requests where certificates were not accepted, most likely didn't reach the server).
If this phase succeeds, then you get eventually a reply from the server. This may take time, you may have to wait 60 seconds. Which is why you do all your internet requests on a background thread. That reply will have a status code (status, not error). The status code is NEVER 0.
By default, iOS doesn't allow http requests, and doesn't allow https requests to unsave servers, so you better use only https unless you have a very good reason. You will need a very good reason to convince Apple to let your app on the app store if you want http requests to succeed. But if you get this wrong, you get an error quite early on.
A status of zero most likely means that a background request didn't finish by the time you read the status, a basic programming mistake. You need to learn how background threads and callbacks work. Without that, you won't be able to use http successfully.
Also google for "Reachability" which can tell you if your app currently has internet access (like when WiFi and Mobile Data are turned off, or in Airplane mode).
I'm experiencing slow response times for my first http POST request to my server.
This happens both in Android and iOS networking libraries. (Volley on Android, and Alamofire in iOS).
First response is roughly 0.7s-0.9s, whereas subsequent requests are 0.2s.
I'm guessing this is due to the session being kept-alive by the server, therefore eliminating the need for establishing a new session on each request.
I figure I can make a dummy request when the app starts to start the session, but it doesn't seem very elegant.
I also control the server side (Node.js) so if any configuration needs to be done there I can also try it.
Investigating a little further, I tried sending an https CONNECT request before issuing the first "real" POST request, and the behavior replicates.
After 30 seconds or so, the connection is dropped (probably at the iOS URLSession level, the load balancer is configured to keep connections as 60 seconds).
In theory this makes sense because setting up an https connection takes up several (12 total) packets and I'm on an inter continental connection.
So my solution is to send a CONNECT request when I expect the user to send a regular request.
I'm developing a messaging system in Delphi. I'm using idTcpServer in my Server Application and idTcpClient in my client application. the client application pings the server every 10 seconds to see if the connection is active and tell the server to set the status of the user to Online. and also the user may send messages to his contacts. all these requests are followed by a response from server which i get by socket.readln command right after i send the request. for example for pinging the server:
TcpClient.socket.writeln('i am online');
if TcpClient.socket.readln = 'ok' then
begin
{commands}
end;
I also check for new messages using Long Polling. I send 'check for new messages ' + timestamp from tcpClient and then on the server, I check the database for new messages newer than the timestamp i recieved in a While loop so when there is a new message the loop breaks and notification is sent to the client.
But this system doesn't work for me. Sometimes I get the responses intended to be for checking for new messages when the client application is pinging the server.
I have developed the same system in php without a problem. but here there must be a problem.
I think it is not asynchronous. what should I do?
Regarding the check for new messages request, the server should not be looping waiting for new messages to arrive. Either there are new messages available at the time of the request or there are not. Get the request, do the query, report the result, and move on. The client can send a new check for new messages request periodically. Alternatively, have the client tell the server one time that it wants new messages, and then the server can actively push new messages to the client in real-time as they arrive on the server, instead of polling for them (similar to IMAP's IDLE command).
I would suggest you redesign your communication protocol to run asynchronously. Most modern IM services are asynchronous. When the client sends a request, do not expect a reply right away. Just let the client move on to other things. Have it run a separate timer/thread that reads all inbound data. When a reply does arrive, the client can act on it. If needed, include an identifier in the request that gets echoed in the reply so the client can keep track of the requests it sends. This also allows the server to use asynchronous processing on its end, so if a request takes a long time to run, the server can push it off to another thread/process and continue processing other requests in the meantime. Send the final reply when it is ready.
i went through this question
Lost messages over XMPP on device disconnected
but there is no answer.
When a connection is lost due to some network issue then the server is not able to recognize it and keeps on sending messages to disconnected receiver which are permanently lost.
I have a workaround in which i ping the client from server and when the client gets disconnected server is able to recognize it after 10 sec and save further messages in queue preventing them from being lost.
my question is can 100% fail save message delivery be achieved by using some other way i know psi and many other xmpp client are doing it.
on ios side i am using xmppframework
One way is to employ the Advanced Message Processing (AMP) on your server; another one is to employ the Message Delivery Receipts on your clients.
The former one requires an AMP-enabled server implementation and the initiating client has to be able to tell the server what kind of delivery status reports it wants (it wants an error to be returned if the delivery is not possible). Note that this is not bullet-proof anyway as there is a window between the moment the target client losts its connectivity with the server and the moment the TCP stack on the server's machine detects this and tells the server about it: during this window, everything sent to the client is considered by the server to be sent okay because there's no concept of message boundaries in the TCP layer and hence if the server process managed to stuff a message stanza's XML into the system buffers of its TCP connection, it considers that stanza to be sent—there's no way for it to know which bits of its stream did not get to the receiver once the TCP stack says the connection is lost.
The latter one is bullet-proof as the clients rely on explicit notifications about message reception. This does increase chattiness though. In return, no server support for this feature is required—it's implemented solely in the clients.
go with XEP-0198 and enjoy...
http://xmpp.org/extensions/xep-0198.html
For a XMPP client I'm working on, the following mechanism is used:
Add Reachability to the project, to detect quickly when the phone is having connectivity problems.
Use a modified version of XEP-0198, adding a confirmation sent by the server. So, the client sends a message, the server confirms with a receipt. Later on, the receiving user will also confirm with a receipt. For each message you send, you get two confirmations, one from the server, one from the client. This requires modifications on the server of course.
When the app is not connected to the XMPP server, messages are queued.
When the app is logged in again to the XMPP server, the app takes all messages which were not confirmed by the server and sends them again.
For this to work, you have to locally store the messages in the app with three possible states: "Not sent", "Confirmed by server", "Confirmed by user"
This question is mostly an HTTP question, I am working on an iOS app, though this question is not specific to iOS.
I would like to use persistent connections, and have no problems doing so, until an HTTP response uses the chunked transfer type, instead of explicitly sending Content-Length. The response itself works normally, and would work if I never needed to cancel the response. This response can take a while to send the response(it can take minutes and will never send the final 0 chunk), and frequently, I would like to cancel this request(and response) and send a new request on the same connection.
With HTTP/1.1, how can I cancel the chunked response response without closing the connection?
My current workaround is to not use persistent connections, but then I lose all the benefits of using persistent connections, which makes initiating these requests much slower.
You can't cancel it. There is nothing in the HTTP protocol that allows you to interrupt a HTTP response. You either need to read and discard the entire response or close the connection. However, you can issue another HTTP request on the same connection while the server is still sending the response, but you still have to process the entire response to the original request.