NWProtocolFramer willMarkReady Can't Read After First Write?

Question

Created Aug ’22

Replies 3

Boosts 0

Participants 2

When creating a framer which will mark ready, we can't seem to get a reply to the first outgoing message sent by the framer, e.g. of the style:

< 220 Service ready for new user.\r\n
> AUTH TLS\r\n
< 234 Command AUTH okay; starting TLS connection.\r\n

The incoming message starting 234 is never received by the framer unless it marks ready right after sending the AUTH line. It looks like this is intentional but we can't understand why this is prevented given the framer should probably check the reply before attempting to prepend e.g. a TLS protocol on the stack (may depend on return code).

The dependency seems to be that marking ready will allow the next read, but prevent prepending, and prepending will immediately trigger the TLS handshake, and it will consume the 234 line. It looks like "pass through" can be called any time, before or after, but that requires another protocol on the stack to do the work.

Do we need to have one framer read the first message and send one message then mark ready and pass through, prepend another identical framer to read the next message then make the decision to prepend TLS, then prepend again for the "decrypted" framer to read the actual application protocol?

We're doing this in C/ObjC, but I figured the Swift terminology might help in the title. Apologies if this was already asked somewhere, I couldn't find a good match.

Boost

Answer 1

TyngJJ OP

Aug ’22

We tried restructuring it this way and figured out part of the issue, you can't deliver or enqueue input or messages of any kind until markReady() (they must be completely consumed), and otherwise that will stall the framer. In the case of TLS any input will be fed into the handshake, corrupting it, and zero-length (with the content stashed in a message) will stall with complete set to true or false.

Is there any way to provide this information back to the connection's receive message handler without triggering this? It seems reasonable that framers should be able to pass this information back (return codes, message text, etc) (after markReady() if necessary), in case of either success or failure. The framer shouldn't have to be completely "silent".

There's the very recent Options subscript, but that doesn't seem to be a good fit semantically.

0

Answer 2

Frameworks Engineer OP

Apple

Aug ’22

Do you have details on how you're processing that input prior to marking ready on the framer? In theory, you should be able to consume bytes as part of that "handshake" and continue to go back and forth until you're good to go and can mark the framer as ready.

1

Answer 3

TyngJJ OP

Aug ’22

The input is parsed into items, which were intended to be delivered "no copy" with a framer message attached. Even if the input is consumed and its contents put in the framer message, delivering zero-length input causes a stall. I was hoping the framer message might be ignored by protocols "above" the framer and passed to the connection "owner".

The key is I was hoping to pass that (processed) input back (at least after markReady()) instead of discarding it. Is it possible for a framer to deliver messages after ready and pass through? Is there another mechanism for making that information available immediately in some kind of queue form?

0