After a client is disconnected from a server, it attempts to reconnect and rebind.
If the server is in a bad state, where it accepts the connection but does not respond to messages, these binding attempts with fail with SMPPCLIENT_RCVTIMEOUT and the socket will be disconnected. The client will then try again. When the server recovers and the client automatically reconnects, the client will erroneously send multiple bind requests, presumably attempting to resend all of the bind requests which previously failed to be responded to when the server was in a bad state.
You can reproduce the server in a bad state by pausing for debugging on the server.
On another related occasion (which I can't reproduce), I also received lots of logs about duplicate sequence numbers being used.
Interesting parts of logs:
Code: Select all
Client when server becomes unresponsive:
12.05.2020 16:21:22:WARN : 63: (SmppClient3) EnquireLink failed. Response Status SMPPCLIENT_RCVTIMEOUT. Sequence 4. InterNetwork/localhost:7799 SystemId: 2-tx
Disconnected event raised.
12.05.2020 16:23:03:WARN : 94: (SmppClient3) Bind failed. Status SMPPCLIENT_RCVTIMEOUT. Repeat in 1 seconds.
Disconnected event raised.
...etc
Server after it recovers: (in this case, restarted)
Client 127.0.0.1:61349 bound as 2-tx
Client 127.0.0.1:61349 bound as 2-tx
Client 127.0.0.1:61349 bound as 2-tx
Client after connection is recovered:
12.05.2020 16:24:35:WARN :138: (SmppClient3) Cannot find request for response BindTransceiverResp, Status: ESME_ROK, Sequence: 10, SystemId: Inetlab.SMPP. Response was received after ResponseTimeout or with wrong sequence_number.