Send iv/salt, target addr with payload altogether #164
Conversation
|
@Anonymous-Someneese Thank you for raising the issue. Please check if this patch could fix your problem. |
shadowaead/stream.go
Outdated
| payloadBuf = payloadBuf[:nr] | ||
| buf[0], buf[1] = byte(nr>>8), byte(nr) // big-endian payload size | ||
| readAndEnctypt := func(buf []byte) (n int, err error) { | ||
| payloadBuf := buf[2+w.Overhead():] |
There was a problem hiding this comment.
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]
There was a problem hiding this comment.
Thank you for the feedback, I fixed this issue in the latest commit.
|
@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 Nevertheless, no method for creating a StreamCipher Writer was exported, and that will be the right behavior of a Writer I think. |
|
Forget it, I can't see a better way without changing |
lixin9311
force-pushed
the
send-header-with-payload
branch
from
1613bde to
8280d39
Compare
|
My question still remains. If a client connects but expect the server to send the first byte. Wouldn't the proxy stuck at |
|
@riobard I've been thinking about it. Although manually fixing it or enabling Nagle's algorithm ( |
|
How much extra delay will be introduced by enabling Nagel's algo just for the first few packets? |
|
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. |
|
We could probably turn off nodelay initially, and turn it back on when we receive the first piece of data from user clients. |
|
Actually I'm wondering if turning off TCP_NODELAY works for the first packet at all? |
Alternative patch of #160
Only tested by CI