Exchange information with a network protocol framer

If we could pass some context into NWProtocolFramer.Options and access it from the protocol framer, that would also solve my problem. Actually it wouldn't solve my problem, for the listener the options are inserted into NWListener and not NWConnection. Rather I need access to the connection itself from my protocol framer, or to storage/context associated with the connection.

How do people solve that problem? It seems to me this is a pretty basic need but it is seemingly impossible to do, am I missing something here?

Rather I need access to the connection itself from my protocol framer, or to storage/context associated with the connection. How do people solve that problem?

One of the default ways that information can be added or retrieved from the frames is by using NWProtocolFramerImplementation and then setting / extracting this data from handleInput and handleOutput. You can take a look at the example for Building a Custom Peer-to-Peer Protocol as this has example of how to do this.

However, if you really want set and gather this information during the handshake then that will not work. Rather you will want to tak a look at the Security Options associated with the connection.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

Thank you for this reply. It doesn't seem like the TLS security options is what I need since I am implementing my own protocol which needs to pass its own custom options (unless I try to abuse these security options by inserting a pointer into some dispatch data object that could be stashed somewhere in there). But it does seem like what I want is NWParameters but for my protocol, alas the Network API does not seem to allow this.

It doesn't seem like the TLS security options is what I need since I am implementing my own protocol which needs to pass its own custom options

I would agree. sec_protocol_options_t does not not allow you to create a custom transport layer security protocol, but rather customize the traditional TLS options, along with inspecting various states of TLS along the way, i.e., cipher suites, protocol versions, and certificates passed back and forth. As a side note here, it is not recommended to create your own version of TLS unless you have a specific reason to do so. And if you need to do this it would require the use of a 3rd party library as we do not provide out of the box support for developing a custom TLS implementation.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

Right, I wouldn't even dare to write a custom TLS implementation. I am implementing custom encryption that will only work with my application on both ends, it's not meant to interoperate with other things.

I thought I might be able to subclass NWParameters to pass custom parameters to my protocol but alas Swift prevents it: although the class is not marked final, it is also not marked open and therefore subclassing is prevented outside of the Network module.