isComplete is not set by upstream protocol in the stack

Question

LaimonaS OP

Created Mar ’21

Replies 3

Boosts 0

Participants 2

I believe this could by a bug in network.framework.

So i've set up simple UDP syslog server using NWListener:

Code Block parameters.defaultProtocolStack.applicationProtocols = [NWProtocolFramer.Options(definition: SyslogProtocol.definition)]

and it works as intended reveiving every UDP message with isComplete flag true in handleInput when framer.parseInput is called.

But if i prepend additional protocol

Code Block parameters.defaultProtocolStack.applicationProtocols.insert(NWProtocolFramer.Options(definition: ValueLengthProtocol.definition), at: 0)

to the protocol stack which simply forwards the message to downstream protocol without any data manipulation

Code Block framer.deliverInputNoCopy(length: length, message: message, isComplete: true)

the downstream protocol receives isComplete false.

So the question is this a bug or what should be done to preserve isComplete flag ?

Boost

Answer 1

Systems Engineer OP

Apple

Mar ’21

But if i prepend additional protocol

What is your additional protocol sitting on top of? Is it UDP or TCP?

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

0

Answer 2

LaimonaS OP

Mar ’21

This particular implementation uses UDP. I've just tested also TCP in another(DNS) framer implementation. Behavior regarding isComplete is the same.

0

Answer 3

Systems Engineer OP

Apple

Mar ’21

and it works as intended reveiving every UDP message with isComplete flag true in handleInput when framer.parseInput is called.

Right, UDP will always send an entire message, it will not read partials bytes on the connection.

I've just tested also TCP in another(DNS) framer implementation.

TCP is just a stream connection in this case and when you have a frame implementation you decide the rules for when something starts and ends on that stream. For example:

Code Block text[[type][length][value]] ... [[type][length][value]]

So sending isComplete to the peer may not be making it until you tear down the connection. If you are absolutely done with your connection and send isComplete along with defaultStream or finalMessage, along with your final transfer, and then take the connection down, does your peer receive these flags correctly?

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

0