Send iv/salt, target addr with payload altogether

[lixin9311]

Alternative patch of #160

Only tested by CI

[lixin9311]

@Anonymous-Someneese Thank you for raising the issue. Please check if this patch could fix your problem.

[oif]

this may results a panic due to index out of range(L49).

max(n) known as payloadBuf size in L47 = bufLength - 2 - overhead, so to get bytes in this line will be 2 + overhead + buf length - 2 - overhead + overhead = overhead + buf length has a extra overhead.

so here should be payloadBuf := buf[2+w.Overhead() : 2+w.Overhead()+payloadSizeMask]

[lixin9311]

Thank you for the feedback, I fixed this issue in the latest commit.

[riobard]

@lixin9311 Since this PR changes the public interface of exported packages, maybe we should version it somehow? So we don't break code using this as dependency.

[lixin9311]

@lixin9311 Since this PR changes the public interface of exported packages, maybe we should version it somehow? So we don't break code using this as dependency.

I think if we generate salt/iv in initWriter/newWrite, it will be ok. But the behavior of NewWriter will be changed.
Create & send salt/iv before creating the Writer -> Writer will automatically create and send salt/iv.

Nevertheless, no method for creating a StreamCipher Writer was exported, and that will be the right behavior of a Writer I think.

[lixin9311]

Forget it, I can't see a better way without changing NewWriter(w io.Writer, aead cipher.AEAD), as long as it takes cipher.AEAD as a parameter.

[Anonymous-Someneese]

My question still remains. If a client connects but expect the server to send the first byte. Wouldn't the proxy stuck at readerWithHeader.Read()?

[lixin9311]

@riobard I've been thinking about it. Although manually fixing it or enabling Nagle's algorithm (SetNoDelay(false)) will fix the issue, there would be a significant latency penalty, and it's bad for some games using TCP (e.g., Minecraft).
I don't think we should fix the signature problem here. Instead, I would recommend using plugins to avoid such an issue.

[riobard]

How much extra delay will be introduced by enabling Nagel's algo just for the first few packets?

[lixin9311]

https://en.wikipedia.org/wiki/Nagle%27s_algorithm#Interactions_with_real-time_systems

Very depending on the use case, and packet size.

If we set a read timeout for a few milliseconds to the underlying TCP socket, and cancel it after the first successful read. There would be little penalty if the server was supposed to send a message first, and we don't have to use sync package (syncing goroutines will introduce more latency).

Anyway, I don't think it is the right place to solve the signature problem in the proxy.

[riobard]

We could probably turn off nodelay initially, and turn it back on when we receive the first piece of data from user clients.

[riobard]

Actually I'm wondering if turning off TCP_NODELAY works for the first packet at all?