I have implemented this golang smpp package (https://github.com/fiorix/go-smpp) in my platform. After sending few SMS, i get a timeout and the sending stops. i.e Sending bulk sms messages to 5,000 contacts, only 500 contacts receive the message then there is a timeout. Kindly help with your suggestions on ow i can sustain the sending without the timeout.
Some of my smpp settings are;
EnquireLink: time.Duration(120) * time.Second,
EnquireLinkTimeout: time.Duration(122) * time.Second,
If you connect with SMPP as client to some SMPP server, the server will impose a idle timeout on your connection and drop the connection. From your side, you must ensure your EnquireLink is shorter than what the server expects, so your client will keep the connection busy and server won't drop it.
I would go for 10 seconds... SMPP is very light protocol (compared to HTTP etc) and one EnquireLink message every 10 seconds is not going to hurt.
I believe EnquireLink setting is how frequent you send EnquireLink and EnquireLinkTimeout is how long you allow the for the server to respond to it - which could be much shorter. So try:
EnquireLink: 10 seconds
EnquireLinkTimeout: 2seconds
Related
is it possible to set a heartbeat or keep-alive for a JMS consumer using QPID JMS? I've found some configuration of QPID which can bet set at the URL like an idleTimeout but I've not found an option to send empty frames for a limited time period.
Regards
The Qpid JMS client allows you to configure how long the idle timeout is which controls when the client will consider the remote to have failed should there be no traffic coming from the remote either in the form of messages or possibly as empty frames in order to keep the connection from idling out. The client will itself respond the the remote peer's requested idle timeout interval by sending as needed an empty frame to ensure that the remote doesn't drop the connection due to inactivity.
If you are seeing drops in connections due to idle timeout on a server then it is likely you have not configured the server to provide an Idle timeout value in the Open performative that it sends to the client.
Reading the specification section on Idle Timeout of a Connection can shed some light on how this works.
as I understand, there is an inactivity time-out in AMQP protocol. It's set to 15 minutes in Azure Service Bus.
Is it possible to change that time-out? OperationTimeout is ignored in case of AMQP protocol.
The inactivity timeout in AMQP protocol is called idle-timeout of a connection. Most, if not all, client libraries support this property. The Azure Service Bus sets this value to 4 minutes. This cannot be changed but a client can set its own idle-timeout to make the service send heartbeats during idle time. If allowed by the library, the application may also overwrite the idle timer interval to send heartbeats more often.
The 15 minute timeout you mentioned seems to be the entity idle timeout. This is Service Bus specific behavior. If an entity (queue or topic) has no activity for a pre-defined time window, the entity is unloaded (meaning all protocol connections are closed). This value cannot be changed. The only way to keep the entity active is by sending messages over the sending link, or keeping an outstanding credit on the receiving link.
I have a client/server setup in which clients send a single request message to the server and gets a bunch of data messages back.
The server is implemented using a ROUTER socket and the clients using a DEALER. The communication is asynchronous.
The clients are typically iPads/iPhones and they connect over wifi so the connection is not 100% reliable.
The issue I’m concern about is if the client connects to the server and sends a request for data but before the response messages are delivered back the communication goes down (e.g. out of wifi coverage).
In this case the messages will be queued up on the server side waiting for the client to reconnect. That is fine for a short time but eventually I would like to drop the messages and the connection to release resources.
By checking activity/timeouts it would be possible in the server and the client applications to identify that the connection is gone. The client can shutdown the socket and in this way free resources but how can it be done in the server?
Per the ZMQ FAQ:
How can I flush all messages that are in the ZeroMQ socket queue?
There is no explicit command for flushing a specific message or all messages from the message queue. You may set ZMQ_LINGER to 0 and close the socket to discard any unsent messages.
Per this mailing list discussion from 2013:
There is no option to drop old messages [from an outgoing message queue].
Your best bet is to implement heartbeating and, when one client stops responding without explicitly disconnecting, restart your ROUTER socket. Messy, I know, this is really something that should have a companion option to HWM. Pieter Hintjens is clearly on board (he created ZMQ) - but that was from 2011, so it looks like nothing ever came of it.
This is a bit late but setting tcp keepalive to a reasonable value will cause dead sockets to close after the timeouts have expired.
Heartbeating is necessary for either side to determine the other side is still responding.
The only thing I'm not sure about is how to go about heartbeating many thousands of clients without spending all available cpu just on dealing with the heartbeats.
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