The trailing ";" may not be removed from the buffer in handleData (formerly receiveBytes)

[Poikilos]

I don't quite understand why handleData (formerly receiveBytes):

self.inboundBuffer = self.inboundBuffer[lastByte:]

Is this is type-o? Maybe it should be self.inboundBuffer = self.inboundBuffer[lastByte+1:] if lastByte is at ";"

I'm not sure because for some reason the loop starts at 2 (for offset in range(2, 9+1):), almost like it assumes the buffer always starts with ";" which seems fragile and possibly will lose the first packet in a session.

[bobjacobsen]

Not sure I understand the second point.

The for offset in range(2, 9+1): loop is indexing through the locations that carry the identifier field. The 2 is because the identifier field is preceded by ':S' at the start of the frame: The ':' was previously found in an if statement and sets the 0 point as being at the index of that.

As the comment just above self.inboundBuffer = self.inboundBuffer[lastByte:] says, "lastByte is index of ; in this message". So that could probably be lastByte+1 in the self.inboundBuffer assignment. But that's not going to lose a packet?

[bobjacobsen]

That should have said ':X' at the start of the frame, I think.

[Poikilos]

Not sure I understand the second point.

The for offset in range(2, 9+1): loop is indexing through the locations that carry the identifier field. The 2 is because the identifier field is preceded by ':S' at the start of the frame: The ':' was previously found in an if statement and sets the 0 point as being at the index of that.

Ok I managed to figure that out today

:X

yes

As the comment just above self.inboundBuffer = self.inboundBuffer[lastByte:] says, "lastByte is index of ; in this message". So that could probably be lastByte+1 in the self.inboundBuffer assignment. But that's not going to lose a packet?

It will leave ";" in the buffer, so next time there will be a ";" before the following ":", but the code never looks before ":" so it is ok, no packet loss. Ok I can improve it to make the code more explicit though.