0

My python program is talking to a device that will delay the conversation by an entire second each time it receives an ack to a push/ack. The conversation is hundreds if not thousands of messages long, so naturally I would like a way around this.

Is there a way to open a connection to my device, keep it open with the intention to send to it but don't ack messages I am receiving back with socket.recv()?

import socket

s = socket.socket()
s.bind(('', xxxxx))
s.connect(('x.x.x.x', xxxxx))

while True:
    try:
        msg = input()
        if 'exit' in msg:
            data = b'I am done now, bye'
            s.send(data)
            data = s.recv(2048)
            print('recieved final message: ' + str(data))
            break
        msg = msg.encode()
        s.send(msg)
        print('sent message: ' + str(msg))
        data = s.recv(2048)
        print('received message: ' + str(data))
        print()
        data = ''
    except Exception as e:
        print(e)

s.close()
  • If the other end doesn’t send >= 2048 bytes then you are relying on the socket timeout which can make everything rather slow. Find your (implementation-specific) socket default timeout using `socket.getdefaulttimeout()` - maybe it’s one second? You can shorten it which will most likely speed things up. Suggest you read and understand the description below the heading ‘Using a socket’ https://docs.python.org/3/howto/sockets.html – DisappointedByUnaccountableMod Sep 23 '20 at 19:02
  • Also read the socket documentation https://docs.python.org/3/library/socket.html – DisappointedByUnaccountableMod Sep 23 '20 at 19:07
  • can you not fix the device? – user253751 Sep 23 '20 at 19:12
  • @barny I thought s.recv(2048) receives at least 1 and up to 2048 bytes and returns immediately unless no bytes were available? – user253751 Sep 23 '20 at 19:13
  • @barny and by default, it waits forever? – user253751 Sep 23 '20 at 19:13
  • @barny In short, I have not messed with the bytes received in some time, definitely while trying to adjust for this issue. That is a good suggestion but I believe it is hard coded on the device I am trying to talk to. I am going to ask for clarification from the embedded engineers tomorrow. – johnywestfife Sep 24 '20 at 03:14
  • @user253751 I can request it be fixed, but I am kind of doing an ad hoc test when I assume there are people in prod that depend on the device to work the way it does currently. – johnywestfife Sep 24 '20 at 03:17

1 Answers1

1

ACKs are essential to send when data are received. Otherwise the sender will simply assume that the data were not received and will try to resent the data. This will essentially stall the communication since only a (initially small) window of non-acked data is acceptable. Therefore it makes no sense to create such a connection and that's why there is no way to do it.

Steffen Ullrich
  • 114,247
  • 10
  • 131
  • 172
  • I get that it is not standard but it seems weird that I can build a connection with socket.accept and just push/ack in return without acking but when I build the socket connection, I just have no choice. You are likely right, I have done a little bit of research and my best hope so far has been using selectors and not blocking the port as I re-allocate it for sending and receiving based on events. – johnywestfife Sep 24 '20 at 03:20