Re-write TCP/IP stack


#1

Hi,

The edlib doesn’t give ACK event, so i need to re-write a lib to support TCP/IP communication with FCM.

Do you know where i can find somes examples, explanations ?
Does some lib already exist ?
Does wavecom will upgrade the edlib ?

thanks.


#2

Hi,
eDlib internally manages all the TCP ACK messages. Hence, you need not worry about reception of your data.

If your are using Open-AT version 3.01 or above, you can give AT+ADLDBG=2 command after you start your Open AT application and then enable the CUS4 -25 level of traces. Here you can see all the IP packets that are sent/received by the module.

Best Regards,
Open AT Fan.


#3

I need to know if packet are really received by the server. I use Q2501B to send GPS position on a server at a specified interval. So, if the server can’t receive those data, i store them into the a&d.

When the connection is lost, data sending will fill the internal buffer. It can take many seconds before the disconnection event. In this case, i can’t know what position was sended or not :frowning:

I’ve the same problem explained in this post : wavecom.com/modules/movie/sc … c.php?t=51

The only way to be sure that data are really received on a server is to reply by a packet “OK”. I can’t do that because we have only 5mb by month on GPRS…


#4

Hi,
One possible method to solve this problem is to find out the time between “data sending using ed_SendDataExt()” and “reception of an Error message indicating that connection is lost”. I think TCP has some predefined timeouts (like 2 minute) for which it would wait before declaring the timeout (please refer to TCP RFC as I am not sure of the time out value) and hence giving the error.

Now, whenever you want to send some data to the server, keep a backup of that data in flash (in case data is too larget) or in some pointer. In case, you do not receive an error within the timeout as calculated above, it means that your TCP segment has successfully reached the server. In this case, you can clear the buffer (or erase the data from flash).

If you received error indicating timeout (i.e. connection lost), you should send the complete data again.

I think that Wavecom modules send the maximum TCP data length of 536 bytes (which is the value that is supported by all the routers in between probably because it is the minimum value of TCP segment that must be supported by any TCP entity). Hence, if you received an error event, you can be sure that none of your TCP data has arrived on the server.

However, I am not sure if it will work, but it is better if this method works rather than implementing complete TCP/IP stack.

Another method is to send Acknowledgement Data by the Web server whenever a TCP frame arrives successfully indicating the length of data received. You can also implement your own protocol which is understandable between your web server and the module. You can add a header before the GPS data which would indicate the packet number that you are going to send along with the length of packet. In case, the web server does not receive all the data of a packet, it can indicate to your module about the packet number and the amount of data it has received so that you can sent it again. However, this method would require you to have access to the web server to program it again.

Best Regards,
Open AT Fan.


#5

Thanks for your help, i understand that there is some way to have a better control on data transmission but they are not “clean” as i would.

I use TCP/IP to have the essential functionnality of this protocol : “Control”.
So i don’t understant why wavecom doesn’t give access to that when every stacks give it !

So, with your suggestion, i’ll try the concept of time between… or porting a stack to openat, maybe uip : sics.se/~adam/uip/


#6

Hi, I have the exact same problem.
I have interchanged conversations with Wavecom but it seems I’m not good at explainig what the problem is. For me the problem is clear:
ed stack doesn’t have a mechanism that tells when a packet has been ack rather than waiting for the connection not to fail on 2 mins (suppousing u send one packet per 2 mins!).

I tried an implementation similar to the one described by OpenAt fan but ended up with many unnecesary retransmited packets and with the posibility of still losing data.

Have you found any solution ?

I’m considering using a third party TCP, but I’m still trying to figure out what can I do with ed, I don’t know if I can do much but maybe intercepting the GPRS flow to check manualy for the acks but i’ll end up implementing TCP myself… :unamused:

Will Wavecom work on this ??


#7

Hi, I have the exact same problem.
I have interchanged conversations with Wavecom but it seems I’m not good at explainig what the problem is. For me the problem is clear:
ed stack doesn’t have a mechanism that tells when a packet has been ack rather than waiting for the connection not to fail on 2 mins (suppousing u send one packet per 2 mins!).

I tried an implementation similar to the one described by OpenAt fan but ended up with many unnecesary retransmited packets and with the posibility of still losing data.

Have you found any solution ?

I’m considering using a third party TCP, but I’m still trying to figure out what can I do with ed, I don’t know if I can do much but maybe intercepting the GPRS flow to check manualy for the acks but i’ll end up implementing TCP myself… :unamused:

Will Wavecom work on this ??


#8

Hi, I have the exact same problem.
I have interchanged conversations with Wavecom but it seems I’m not good at explainig what the problem is. For me the problem is clear:
ed stack doesn’t have a mechanism that tells when a packet has been ack rather than waiting for the connection not to fail on 2 mins (suppousing u send one packet per 2 mins!).

I tried an implementation similar to the one described by OpenAt fan but ended up with many unnecesary retransmited packets and with the posibility of still losing data.

Have you found any solution ?

I’m considering using a third party TCP, but I’m still trying to figure out what can I do with ed, I don’t know if I can do much but maybe intercepting the GPRS flow to check manualy for the acks but i’ll end up implementing TCP myself… :unamused:

Will Wavecom work on this ??