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 − 吉

src/sock/enc.rs

@@ -462,7 +462,8 @@ 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... 
+//     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