Network protocol framer and receiving partial messages

Question

Created Jul ’21

Replies 4

Boosts 0

Participants 2

It was my understanding that the protocol framer would accumulate data until it is consumed, which I would do by returning a non-zero value from the framer.parseInput() block or by calling deliverInputNoCopy().

However it does not seem to be the case, at least not across severals calls to handleInput(). Per my testing, I am unable to parse the needed amount of data across several calls to handleInput().

Is it correct that the non-consumed data is dropped between calls to handleInput() and our implementations need to take care to accumulate partial data across several handleInput() calls?

And if it is correct, I'm also quite confused by the TicTacToe sample code because it does not seem to worry about receiving a partial header. Is this a bug in the sample code?

Boost

Answer 1

tclementdev OP

Jul ’21

Or is there some buffer size limit above which the framer would stop receiving more data? It's as-if it never receives the end of the data even though the other side has sent it. My code can't parse the needed amount and handleInput() stops being called.

0

Answer 2

tclementdev OP

Jul ’21

Further testing indicates the latter: data is not dropped but the framer fails to receive more data, and even though handleInput() is called again, the buffer does not contain more to parse. Consuming the available (partial) data seems to unblock the situation as the framer is then able to receive the missing piece of the data.

Is this the correct behavior? Am I trying to parse too much data at once? If so, what is the upper limit we can parse without possibly entering this deadlock situation?

0

Answer 3

Systems Engineer OP

Apple

Jul ’21

Further testing indicates the latter: data is not dropped but the framer fails to receive more data, and even though handleInput() is called again, the buffer does not contain more to parse.

One way to try and avoid some of these headaches is by adding a length value in your packet header. This can be within the first few bytes of your header. Then, parse they first few bytes in handleInput() to read out your packet body length from your header. With the rest of handleInput() try to read the entirety of the packet body using the length value sent in the header to be passed into deliverInputNoCopy. If you need extra help with this, open a TSI and I can take a further look.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

0

Answer 4

tclementdev OP

Jul ’21

I do have a length value in the packet header but I can't call deliverInputNoCopy because my protocol needs to look at all the data (doing custom encryption/decryption, not TLS on purpose). Therefore I am trying to parse the whole length read in the header.

I have seen nothing in the documentation or wwdc sessions about the framer.parseInput() API potentially starving depending on the minimum amount of data requested. Would you be so kind to at least give us the range of values we can expect to pass safely to the API?

0