+KTCP_DATA with large data

Hello!

Hardware: BHL7800-M
Firmware: BHL7800-M.3.7.2.3.20191030

I have a general question regarding the handling of +KTCP_DATA responses with large receive data (>20000 bytes).

In general, after sending data, we are waiting for the unsolicited responses +KTCP_DATA: 1,<ndata> in the following way:

(After transmit completed, radio drops back to command mode) …

--EOF--Pattern--
OK

+KTCP_DATA: 1,1300 <-- First 1300 bytes are ready to be received

AT+KTCPRCV=1,1300 <-- Start receiving 
CONNECT
HTTP/1.1 200 OK
Cache-Control: private
Content-Type: application/octet-stream
 
.... data...
--EOF--Pattern--
OK

Now, switch back to command mode and wait for the next unsolicited +KTCP_DATA: 1,<ndata> response.

Continue this until all bytes received.

Questions:

  1. Is there any way for the radio to know how many total bytes are sent, or do we need to parse the TCP header to determine this?
  2. Is there any indication from the radio that it is done receiving data, or should we rely on “server closed the connection” notification after all bytes received? Is this a reliable way to do this?

Thanks

Hi @rlemburg,
Questions:

  1. Is there any way for the radio to know how many total bytes are sent, or do we need to parse the TCP header to determine this?
    [J]: As soon as the connection is established, the module can receive data through the TCP socket. This notification is sent when data are available in the receive buffer. This notification is sent for each TCP packet received sequentially; notification of the following received packet is sent only when the current +KTCP_DATA has been read with a +KTCP_RCV command.
    You can refer to 9.11.8. +KTCP_DATA Notification: Incoming Data through a TCP Connection in below link for more detail
  2. Is there any indication from the radio that it is done receiving data, or should we rely on “server closed the connection” notification after all bytes received? Is this a reliable way to do this?
    [J]: When all bytes have been received, the module returns to command state and returns OK.
    You can refer to 9.11.3. +KTCPRCV Command: Receive Data through a TCP Connection
    https://source.sierrawireless.com/resources/airprime/software/airprime_hl78xx_at_commands_interface_guide/#sthash.4t8Rpzgj.dpbs
    Please help to check Solution if your question is answered
    Thanks

Thanks, Jerdung.

Yes read all of that. The AT command guide is not 100% clear and explicit, which I why I ask for clarification. Here’s sort of what I think the answers might be, in case someone else sees this post:

  1. Is there any way for the radio to know how many total bytes are sent (I mean by the server here), or do we need to parse the TCP header to determine this?

Looks like KTCPSTAT should work.

  1. Is there any indication from the radio that it is done receiving data, or should we rely on “server closed the connection” notification after all bytes received? Is this a reliable way to do this?

I think I answered my own question here - just use AT+KTCPSTAT to inquire the <rem_data> (see 9.11.10).

Typically, with standard AT commands in B2B data enrichment tools, there isn’t a direct way for the radio to inform you about the total number of bytes being sent. You might need to rely on parsing the TCP headers or other means to determine the total size. This is a common approach when working with raw TCP data.

The “+KTCP_DATA” response you receive doesn’t inherently indicate the end of the data stream. You generally have to rely on contextual information. If you’re dealing with an HTTP response, for example, in B2B data enrichment tools, you might look for the end of the HTTP message (like the “Content-Length” field in the header or the closing of the connection). Alternatively, if the server closes the connection, it can be an indicator that all data has been sent.

Using “server closed the connection” as an indication can be reliable if the server follows the proper protocol and closes the connection when it’s done sending data. However, keep in mind that in some cases, servers might keep the connection open for potential further communication.

If you have control over the server in B2B data enrichment tools, you can design a protocol where the server sends a specific message indicating the end of data transmission. This can enhance the reliability and predictability of the data transfer process.