EHS6T : Message send from server arrive too late to the modem | Telit Cinterion IoT Developer Community
January 31, 2017 - 11:31am, 2144 views
Hi,
I'm using this modem :
Cinterion
EHS6
REVISION 03.001
A-REVISION 00.000.31
I'm sending messages from the server to the modem (client). In the modem program, I open a socket like this:
String s = "socket://" + m_sAdresse + ":" + m_iPort;
try
{
m_sc = (SocketConnection) Connector.open(s);
}
And I stream data like this :
InputStream m_is = m_sc.openInputStream();
Output stream m_os = m_sc.openOutputStream();
Sending message from the server works well most of time. But sometimes, the server send a message but he did not arrive to the modem. One minute later, server retry sending the same message, the modem receives the two message together.
When it works the modem receives 14 bytes like this:
[Mon Jan 30 12:00:04 2017] 0000 02 30 4D 57 48 5A 41 26 5A 39 45 4F 40 03 .0MWHZA&Z9EO@.
But when we have a bug, the modem receives 28 bytes like this:
[Mon Jan 30 12:19:33 2017] 0000 02 30 4D 57 48 5A 41 26 5A 39 45 4F 40 03 02 30 MWHZA&Z9EO@.
[Mon Jan 30 12:19:33 2017] 0010 4D 57 48 5A 41 26 5A 39 45 4F 40 03 MWHZA&Z9EO@.
On the server, we see that we have sended two messages.
The 3G network is good.
We have also seen that if we send a message every 5 minutes we haven't the problem, but when we wait over 40 minutes we have the problem. The socket KEEPLIVE flag is set.
Thank you for your help.
Hello,
So you wait 40 minutes, send the data and if it does not reach the destination you send it again? If you know that it didn't reach the module you probably wait for some kind of confirmation on the application layer which doesn't come?
Socket connection is a kind of stream connection where you open a stream and read or write data. So there is no separation between the portions of data. The TCP only guarantees that the sequence is correct - the particular packets on TCP layer can even come in a different order to the destination but your application will receive it in a right order. So I don't see anything wrong in the fact that the data sent with a delay may come at the same time or the portion of data sens at the same time may come delayed.
More interesting is that the data which did not come right after sending arrives just together with another portion of data that was sent a minute later.
But so far we don't know if the data was delayed in a network (which seems possible) or didn't leave the server or came to the module. Did you try to wait longer to see what happens? Have you tried to trace on TCP layer if the data was really sent form the server? Have you tried to send more data at a time?
Generally the TCP provides retransmissions so it should not be necessary to send the data again on the same connection. If the data doesn't come for a long time the connection could be assumed as broken.
There is a KEEPALIVE parameter in the API but as far as I know this functionality is not supported by the platform. Generally not all platforms/implementations support this.
Best regards,
Bartłomiej
Hello,
Thank you for your answere. To try to see what is exactly the problem, I'm creating a new small program because the first one is too complicated. I connect the modem to the server, then I listen what the server sends. So with this small program I will continue the investigations.
Hello,
I have made sample program to test the communication with the server. And I found something "strange".
Our software is an update of one existing in an other modem, so in our previous version we set KEEPLIVE socket option.You said that the KEEPLIVE parameter is not supported. But when I remove this flag the datas arrives in time. And when I set this flag, the datas arrives late.
I don't understand this case, Do you see an explanation ?
Best regards,
Mohammed.
Hello,
Very interesting behavior. I think that tracing on the TCP layer would be helpful here to discover if this setting changes something in communication. Do you have a possibility to trace on server side? Can you share your test application so I could try on my side?
Regards,
Bartłomiej