I couldn't find any push notification document saying we can make xx number of requests per day.
I execute a cron which runs every 5 minutes, and on run it will open a connection, send the notification and disconnect.
Will this create any issues, 5 minutes cron a day means 288 request (or connection open and close). Will apple consider this as Denial of Service attack.
Please advise.
Suppose we need to send 500 notifications at a time then it is not a good practice to open a connection, send notification and then close connection. Instead we can open a connection, put a loop for sending 500 notifications and then disconnect it when all are complete.
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.
I have an application in which clients use websockets to connect to a server which is running Spring Boot Tomcat.
My question is if there is a way for the server to detect a client disconnect due to a network loss.
Thanks.
if you are using stomp , check SessionDisconnectEvent.
For raw Websocket connections, you can use :
WebSocketHandler-->afterConnectionClosed
I have searched before for this and the solution I was able to find was to implement a ping-pong mechanism between the server and the clients.
For example, each few seconds send a dummy message to the client on a specific topic and receive back another dummy reply, if you didn't get a reply for a configured period you can consider the client disconnected.
As mentioned here,
STOMP and Spring also allow us to set up topics, where every
subscriber will receive the same message. This is going to be very
useful for tracking active users. In the UI, each user subscribes to a
topic that reports back which users are active, and in our example
that topic will produce a message every 2 seconds. The client will
reply to every message containing a list of users with its own
heartbeat, which then updates the message being sent to other clients.
If a client hasn't checked in for more than 5 seconds (i.e. missed two
heartbeats), we consider them offline. This gives us near real time
resolution of users being available to chat. Users will appear in a
box on the left hand side of the screen, clicking on a name will pull
up a chat window for them, and names with an envelope next to them
have new messages.
I am writing code to support APNs communication on a server. I am anticipating push notifications to be triggered frequently. Is there ever a reason I should intentionally close my connection with APNs and reopen later? e.g. If there happens to be ~1 minute break between any notification.
I have setup an Indy IdFTP Client to a FileZilla FTP Server.The client tries to Connect on startup of my app and, If it fails, keeps retrying every few seconds for the lifetime of the app. In addition, I need to detect if I lose the connection and, again, keep trying to re-establish the connection. This is where I am having a problem.
I have added an OnStatus event handler which seems to fire for all the event types except hsDisconnecting and hsDisconnected.
I also have an OnDisconnected event handler which only fires when I have locked the Server, in this case, when I try to connect, it fires the OnConnected then immediately fires the OnDisconnected. However, if I set the Server as not Active after the initial successful connection, the server tells me it has disconnected me but I do not get an event in my code so I don't know I need to start trying to connect again? Am I wrong in expecting these events in this scenario, is there something else I should be listening for?
Thank you in advance for your help.
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...