TransferBytes and UncompressedBytes are always zero for text receives

[Jacalz]

I was looking at comparing the .CompressedBytes64 and .TransferBytes64 of *IncommingMessage to compare how much the compression managed to save. However, what I found was that they both were zero for text sends. The same thing occurred with the same variables without the 64 postfix. I can understand if the text perhaps isn't compressed and that it then would be equal to the transfer bytes but it would be good if the transfer bytes would show how many bytes of text there are.

My use case for this is to have a bytes.Buffer that I grow the the amount of bytes received in order to be able to not append to the buffer each time and thus improve performance. It turns out that I have been growing it with zero each time, for quite a long time...

[psanford]

Thanks for raising this.

First some background on why it works the way it does today. The CompressedBytes and TransferBytes are primarily there to show to the receiver before they accept a file (or directory) transfer, allowing them to reject files that may be too large. They are fields that are part of the offer sent by the sender via the rendezvous server for files and directories. This happens before a direct connection is made between the two clients. Text messages work a little differently. The full contents of the text message is stored encrypted in the mailbox on the rendezvous server. This means that there is no opportunity to reject the message before fully receiving its contents.

Given that one of the goals of the API was to be as consistent as possible between the different types of offers, I think its reasonable to populate these fields. However, I think we should clearly document that the for Text messages, the size is populated by fully receiving the message in memory and that you can't reject a text message at that point.