Use memory-aligned data structures in qmux protocol about qmux

[progrium]

Oh, fascinating. Definitely open to it. For reference/docs here is more info I found: https://developer.ibm.com/technologies/systems/articles/pa-dalign/

So this would be for all messages I'm assuming?

[awakecoding]

Yes, this would be for all messages. If am I to fix the message alignment, I might as well define a common header structure to make it much easier to know the expected message size. I will make significant changes to the document structure, and then you can take a look and see if you want to adopt the changes. It would be great if we end up both using a common protocol, otherwise it's no big deal, I'll just use a different name. I also want to ensure that the protocol can evolve with some backward compatibility.

[awakecoding]

@progrium okay, I've begun my work and I am clearly going to redesign the whole thing my way at this point, so you may not want to the final result when I'm done. We still have a common goal, so there are bits and pieces we can share. I've reviewed QMUX and the original SSH protocol, and there's one thing that eludes me so far: how would you support SOCKS5 on top of QMUX?

OpenSSH has this nice SOCKS5 tunneling feature that is an improvement over the regular TCP tunnel, and I intend to support SOCKS5 as well. However, I couldn't find the part of QMUX or the original SSH protocol that lets you specify the destination of the channel to open (IP address or hostname + port). Unlike a tunnel with a fixed destination, SOCKS5 requires that you specify where to connect. Is this something you wanted for QMUX as well?

[awakecoding]

Here's my draft revised protocol draft, let me know if you're interested, otherwise you can just close this issue and I'll move on with my own variant: https://github.com/awakecoding/qmux/blob/protocol-update/SPEC.md

[progrium]

I like some of the improvements but you're right we might be diverging pretty quickly. Is there a benchmark or test that could be done to show the performance difference of memory-aligning vs not (assuming a target platform/architecture)?

[awakecoding]

I don't have benchmarks, but to be honest, the performance will likely be very similar. It is just a good idea to pre-pad the data structures so the compilers won't, making it much easier to just transfer data structures as-is with minimal transformation between the wire format and the memory format (aside from little endian vs big endian).

I don't want to steer you in a different direction, I have already modified the protocol beyond recognition with the following:

• structure memory alignment
• common header structure
• maximum fragment size (65535)
• type-length-value (TLV) encoding
• move variable-length field to body
• assign 'variable' names to each field
• channel destination URL encoding
• reintroduce reason code and string

This new draft is what I'll use for my V1 of "JMUX" in jetsocat. It'll mostly be interesting to follow what happens on my side, but it's no longer relevant for QMUX unless you wish to significantly change it and take the same direction I'm taking.

I'll close this issue, thanks for your help