This bug may make ESock **unusable** in this project entirely. Individual `SerializedMessage` sending/receiving _might_ work reliably since that is based on rigid size communication, but streamed data may be untenable. Any desync in streaming buffers causes complete failure.

This really is unacceptable but I don"t even know where to start to find the issue with it. It is likely a very deep design flaw with how we interact with the cipher, making this bug impossible to fix without a complete rewrite. Just like all other software I write. Worthless.

Fortune for rsh's current commit: Blessing − 吉
master
Avril 3 years ago
parent 2a3d9e0c3a
commit f8b6e3a0c6
Signed by: flanchan
GPG Key ID: 284488987C31F630

@ -463,6 +463,7 @@ impl<W: AsyncWrite+ Unpin, R: AsyncRead + Unpin> ESock<W, R>
//XXX: For some reason, non-exact reads + writes cause garbage to be produced on the receiving end?
// Is this fixable? Why does it disjoint? I have no idea... This is supposed to be a stream cipher, right? Why does positioning matter? Have I misunderstood how it workd? Eh...
// With this bug, it seems the `while read(buffer) > 0` construct is impossible. This might make this entirely useless. Hopefully with the rigid size-based format for `Message` we won't run into this problem, but subsequent data streaming will likely be affected unless we use rigid, fixed, and (inefficiently) communicated buffer sizes.
impl<W, R> AsyncWrite for ESock<W, R>
where W: AsyncWrite

Loading…
Cancel
Save