I’m using HL6528 to create a TCP socket as a client and connect to a server.
Periodically I check socket status by using AT+KTCPSTAT and, if I get a response like this:
+KTCPSTAT: 3,-1,0,0
I assume that the socket is UP and I can do read and/or write operations.
In which case, i.e. for which values of status and/or tcp_notif fields should I consider the socket down and try to reopen it and reconnect to the server? Are these values somehow related to cellular network quality of signal (CSQ)?
No they are not related to network quality at all, in theory the sockets, since they are at a higher level, can survive loss of the signal temporarily although in practice the outage can only be quite small.
Also note the socket status will only change if the unit explicitly receives a notification from the other end that it is closing down the socket (i.e. time out, it wants to, etc), so if the network closes the connection because of lack of use or the notification comes through while the unit is out of coverage and it is not re tx/the network discards it then it won’t actually be connected but the status will say it is.
Thanks for your reply.
I’m receiving state like this:
+KTCPSTAT: 1,4,0,0
when the network rejects the unit because of opening an already existing data session.
Should be status=1 (or 2) considered as a reason for reopening the socket, or should I consider only status=4 (or 5) as a definitive closed socket that may trigger a reopen?
I noticed that, with a lack of coverage (GPRS antenna removed), the status becomes:
+KTCPSTAT: 5,4,0,0
after few minutes (and here I try to reopen the socket, but unsuccessfully because of NO CARRIER). Is this because of socket timeout due to inactivity?
5 is the only state where you can consider the socket completely closed by the unit having gone from and opened state, I do not know what the criteria is to go from 5 back to 1, probably deleting the socket. The safe way is define the socket, open it, use it then if you get a status like 4 or 5 then close or delete it and start again.
Re the state 5 you are seeing, I do not know the details but you have probably been trying to send data while the unit is out of coverage at which point the TTL will expire (set to 64 I think) and the socket will shut down. At a guess.
Thanks for your reply. You’re right, I was trying to send something while the unit was out of coverage… until I got +KTCPSTAT: 5,4,0,0 and at that point I retried to open the socket and connect.
Generally speaking, I perform the following sequence in client mode:
AT+KCNXCFG
AT+KTCPCFG
AT+KTCPCNX
Periodic loop (while client goes to sleep and socket is UP):
a. get TCP socket status periodically
b. receive data, if any
c. send data, if any to send
AT+KTCPCLOSE
AT+KTCPDEL
Here my questions:
Which of the above commands automatically create and destroy a PDP context?
Which should be the maximum timeout to wait for response from AT+KTCPCNX?
If point 3. fails for any reason (or if socket gets unexpectedly CLOSED at point 4a), I jump to 5 and 6, then retry to configure TCP and to connect (point 2 and 3), then enter loop. Is this correct?
What should I do in case of failure to reopen socket and reconnect to server avoiding to duplicate a PDP session (that results in reject by the network)?
at+ktcpcnx starts the PDP context and then opens a TCP socket.
There isn’t really a timeout for this command but practically I would say 30 seconds is the outside, if it has not completed or explicitly failed then something further up the line has broken and it is highly unlikely to finish so abort it.
If a socket is unable to be opened and you are sure that you are in coverage (at+cgreg? is 1 or 5) and the APN you are using is correct all you can really do is try to re open the socket, if the PDP context is failing (i.e. because the APN is wrong) then it should come back with an error code indicating this pretty quickly.