<p>So I just now defeated this <strong>ANNOYING AF</strong> issue due to my own ignorance. Basically the tl;dr is please keep in mind that TCP is a <strong>streaming</strong> protocol when getting fancy with raw connections.</p>
<p>So here's the setup:
I had a raw TCP connection that I wrapped in my own ReadWriter so I could create custom Write and Read methods that utilized some crypto functions to encrypt/decrypt data. So far so good right?</p>
<p>Normally I'd be able to call it a day. However I have been trying to speed code a new protocol for data transfer and decided I'd use the gob package to speed up prototyping of this. Basically I didn't want to create packet-specific serialization just yet because <em>yawn</em> who has time for that. </p>
<p>So, I am testing the protocol out and I get through discovery, no problem. Now on to key exchange... again no problem transferring data using the gob encoding. Now it comes time to create my crypto device and implement the encrypted form of my connection. A couple of test packets and SUCCESS!</p>
<p>Okay well this isn't that exciting but still, things were working. Then I send another set of packets and suddenly I'm getting an error related to the crypto device being unable to work properly. After some digging it turned out that the a public nonce I was transferring was inconsistently being encountered. </p>
<p>I spent an hour verifying that the messages sent were correct and had the expected bytes. Now for those that aren't familiar with gob, basically it will send the type information first, then send the values (later just the type id and values after type info caching IIRC). One with my forgetfulness about TCP would expect this to be carried in two separate "packets" since they utilize separate write calls. Naturally I checked to ensure I had two separate calls to write. I did and they were of the expected lengths after encryption.</p>
<p>MY MISTAKE (aside from remembering that TCP is inherently a stream protocol) was that I didn't immediately check what I was receiving on the other side of the connection, assuming two calls to Write() ended up with two packets. Finally out of frustration I decided to check and lo and behold I was getting a read length on the remote side of the connection that equaled the combined length of the two writes.</p>
<p>This posed a problem because I was requiring that each write uses a separate set of conditions so that each could be decrypted on its own. Thus, when I received the combined packet, I was decrypting with only my first set of conditions over the whole of both sets I expected, generating what was essentially jibberish to the gob decoder.</p>
<p>Now, the short-term fix for this is of course to append the expected length to correctly partition streamed data into packets, then decrypt, then decode. I patched this only 5 min. ago and it's working peachy but now I'm regretting being lazy and not being more explicit about my data serialization and using Gob.</p>
<p>So, to conclude:
I'm sure there are more elegant ways to do what I am trying to accomplish, however I attempted to use a custom ReadWriter with gob and in the end a TCP stream buffer screwed me over. My overall message is that if you have issues like I did with using specialized interfaces with other encoders/decoders over a connection, perhaps the issue is that the data is combining in the pre-transmission buffer then being transmitted together when you are expecting discrete packets over TCP. </p>
<p>Happy coding I guess, I'm gonna bang my head against the wall and give up one of my "programmer" cards. Cheers!</p>
<hr/>**评论：**<br/><br/>danredux: <pre><p>This is pretty funny.</p>
<p>You don't need to send any message-length type stuff, though. Just use a streaming encryption scheme instead of a message-based one.</p></pre>
