isComplete is not set by upstream protocol in the stack

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 ?
Up vote post of LaimonaS Down vote post of LaimonaS
506 views
Posted by
LaimonaS
Reply
Add a Comment

Replies

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
Posted by
meaton
Up vote reply of meaton Down vote reply of meaton
Add a Comment
This particular implementation uses UDP. I've just tested also TCP in another(DNS) framer implementation. Behavior regarding isComplete is the same.
Posted by
LaimonaS
Up vote reply of LaimonaS Down vote reply of LaimonaS
Add a Comment

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
Posted by
meaton
Up vote reply of meaton Down vote reply of meaton
Add a Comment