0

I have a python application running on an IOT device which is receiving data over a bluetooth (pybluez) connection. I'm testing the IOT device with an android phone. Most of the protocol is small chatty packets, however, there's one operation which requires sending a larger amount of data all at once, about 58K in my current test.

It works sometimes, but more often than not it hangs waiting for additional data that never comes. I suspect this means I'm either overflowing some limited size buffer and dropping data, or the transport is unreliable and some data is being dropped.

The code I'm using to read the data looks like this:

# Read the boundary off the socket
borderDataSize = borderPoints * 16
while len(data) < borderDataSize:
    newdata = client_sock.recv(4096)
    data += newdata

# ... logic to process the data ...

Has anybody experienced this? I don't think i've ever seen this with my smaller chatty communications running in a loop, does this mean it's probably some sort of buffer overrun? Are there any best practices for dealing with this problem?

James Suffolk
  • 213
  • 1
  • 12
  • You said you have "about 58K" data. So you do not know the exact size of data to expect? Think about what happens when the actual size of data is less than borderDataSize and the difference is more than 4096. In that case, you will read all the data from socket and in next iteration block on recv. That is most likely what is happening in your case. – singhatulks Sep 15 '20 at 07:23
  • 1
    There are various ways to handle cases where you do not know exactly how much data to expect. One simple way is use [socket.settimeout](https://docs.python.org/3/library/socket.html#socket.socket.settimeout) and catch socket.timeout exception; then you can process the data to see if you have the complete data or not. You could use the MSG_PEEK flag as well, but I haven't tried it in python. – singhatulks Sep 15 '20 at 07:32
  • @singhatulks I should’ve added that the data size (borderpoints) is sent in the protocol and that I’ve verified the byte count on the client matches with prints. Setting a time-out is a good suggestion, too – James Suffolk Sep 15 '20 at 12:27

0 Answers0