Without timeout? Or is there even a timeout?
There is no limit on the lifetime of a connected jid. For command line bots, it is a good practice to send periodic ping packets to the server, just to make sure opened socket doesn't drop after some period of inactivity.
In case your client is connected from browser and suppose the user refreshes the browser without disconnecting from the jabber server. User can still use saved (via cookie/session) jid,sid,rid combination to reconnect with previously opened session. However, bosh connection manager will drop the connection after "X" seconds of inactivity.
XMPP does not say anything about having or not a timeout. So, in theory, you XMPP Session could last as long as the TCP connection is established.
You are free to implement a timeout in your client or server though...
Related
I use mailkit for my ASP.Net Core application and create a SMTPClient object which I then connect to Office365 and authenticate my user with a username and password. How long can this connection be open until it expires or needs to be reauthenticated? Also, is there a way to keep the connection alive without sending an email at the expiration time?
To keep a client connection to a server alive (whether it be using the ImapClient, Pop3Client, or the SmtpClient), you can use the NoOp() or NoOpAsync() methods to send a command to the server that does "nothing" but to let the server know that the client is still there and wants the connection to remain alive. At least in theory this will work.
That said, it's likely not considered good netiquette to keep an SMTP connection alive for any lengthy period of time.
Most SMTP servers are going to expect clients to connect, flush their outbound message queues (by sending each message that is queued up) and then immediately disconnecting and some of the bigger free mail servers may ignore NOOP commands and disconnect the client anyway after some set period of time.
For example, the IMAP specification states that servers should keep a connection alive for at least 30 minutes after the client's last command, but in practice, GMail will only keep that connection alive for less than 10 minutes.
The SMTP specification, as far as I can remember off the top of my head, makes no such suggestion as far as how long to keep the connection alive after the client's last command, so some servers may require more frequent NOOP commands than others and some may even have a max period of time that they'll allow you to keep that connection alive for regardless of whether you send those NOOP commands.
TL;DR:
The NOOP command (via the NoOp() or NoOpAsync() methods) will theoretically keep the connection alive if sent frequently enough, but I would not depend on this working reliably.
How connect to https://api.push.apple.com using http2 with persistent connection ?
Persistent connection is to avoid rapid connection and disconnection:
APNs treats rapid connection and disconnection as a denial-of-service attack
https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/APNsProviderAPI.html
Is writing a client in c using https://nghttp2.org the only solution?
(If that question should be ask in another StackExchange website, please do tell me)
Non-persistent connections are a relic of the past. They were used in HTTP/1.0, but HTTP/1.1 already moved to a model where the connections were persistent by default, and HTTP/2 (also being multiplexed) continues on that model of connections being persistent by default.
Independently on the language you are using to develop your applications, any HTTP/2 compliant client will, by default, use persistent connections.
You only need to use the HTTP/2 client library in a way that you don't explicitly close the connection after every request you make.
Typically these libraries employ a connection pool that keeps the connections open, typically until an idle timeout fires.
When your application makes HTTP requests, the library will pick an open connection and send the request. When the response arrives the library will not close the connection but instead put it back into the pool for the next usage.
Just study how the library you want to use allows you to make multiple requests without closing the connection.
I also met this question!
If the connection be idle for a long time (about 1 hour), then function poll catches no socket status changed. It always returns 0 even as on_frame_send_callback was invoked.
Is there anyone can figure out the problem?
How does the server and client keep the TCP connection open? Is it heavy on the system both cpu-wise and/or network-wise even if the connection is idle?
I found a good article about it http://www.tcpipguide.com/free/t_TCPConnectionManagementandProblemHandlingtheConnec-3.htm
It explains that when a TCP connection is idle, nothing happens on the network and when they need to send data the connection simply opens again.
Some people think the use of "keepalive" messages is necessary to limit the number of idle connections open, and to ensure that no 'broken' connections are kept open.
Others think the keepalive messages are a waste of resources, And possible accidental server disconnection problems.
I'm using uwsgi's websockets support and so far it's looking great, the server detects when the client disconnects and the client as well when the server goes down. But i'm concerned this will not work in every case/browser.
In other frameworks, namely sockjs, the connection is monitored by sending regular messages that work as heartbeats/pings. But uwsgi sends PING/PONG frames (ie. not regular messages/control frames) according to the websockets spec and so from the client side i have no way to know when the last ping was received from the server. So my question is this:
If the connection is dropped or blocked by some proxy will browsers reliably (ie. Chrome, IE, Firefox, Opera) detect no PING was received from the server and signal the connection as down or should i implement some additional ping/pong system so that the connection is detected as closed from the client side?
Thanks
You are totally right. There is no way from client side to track or send ping/pongs. So if the connection drops, the server is able of detecting this condition through the ping/pong, but the client is let hung... until it tries to send something and the underlying TCP mechanism detect that the other side is not ACKnowledging its packets.
Therefore, if the client application expects to be "listening" most of the time, it may be convenient to implement a keep alive system that works "both ways" as Stephen Clearly explains in the link you posted. But, this keep alive system would be part of your application layer, rather than part of the transport layer as ping/pongs.
For example you can have a message "{token:'whatever'}" that the server and client just echoes with a 5 seconds delay. The client should have a timer with a 10 seconds timeout that stops every time that messages is received and starts every time the message is echoed, if the timer triggers, the connection can be consider dropped.
Although browsers that implement the same RFC as uWSGI should detect reliably when the server closes the connection cleanly they won't detect when the connection is interrupted midway (half open connections)t. So from what i understand we should employ an extra mechanism like application level pings.
One of my app need socket connection.
I tested on nitrous.io, but their free account always close the socket connection if there is no signal between server and client more than 1 minute.
Just wonder if there is similar socket connection limitation on heroku?
Your comment welcome
Heroku has support for WebSockets, with the usual 30s timeout limitation. This can be easily worked-around by sending heartbeat packets.
https://devcenter.heroku.com/articles/heroku-labs-websockets