Implement protocol receive operations about iris-java

[evfool]

recvByte and recvBool seem to be implemented, do they need to be reimplemented? A possible problem I see with them is that recvByte receives a Java byte (signed) unlike iris-go recvByte, which receives a Go byte (unsigned). To have feature-parity between iris-go and iris-java, we should use char in Java. Unfortunately when replacing byte with char in the sendByte and OpCodes, the handshake test fails, and I can't figure out why. Ideas, anyone?

[paplorinc]

We shouldn't use chars, use shorts or ints instead.

[paplorinc]

I have implemented the recv functions, but the whole interface is so coupled, that I cannot test the Send and Receive functionality in separation (e.g. to replace the socketIn and socketOut with in memory streams, so that I don't need anything else to validate the sent and received data).
This is one of the reasons why I suggested the separation of concerns.
Will try to resolve it somehow, if you don't like it, I will change it back.

[karalabe]

@evfool
I just added recvByte/Bool to make teh list complete. Sorry that I forgot to check them.

Receiving a Java byte is not a problem. A byte is a byte. The protocol concerns itself only with the 8 bits of that byte, it doesn't interpret them as numbers, so being signed or unsigned is irrelevant. Char doesn't work since it is 2 bytes long (same for short and int (4)). Additionally, since the only the opcodes use bytes (and the implementation of the varints), the signedness doesn't complicate things. So keep the byte as a byte.

@paplorinc
Actually, there is still a simple way to test it by going through a local network socket. IMHO it is simpler than introducing additional moving components just to test the functions. Open a server socket, and voila, you have the other end of the stream to test.

Note, however, that I think unit testing individual sends/receives will backfire during minor protocol updates (and as I'm preparing the second draft of the relay protocol, that will be soon (i.e. days, max a couple weeks)). The reason is that any updates will require rewriting all the tests. Since the binding itself is a very simple component, I think integration tests are enough, and are much more flexible and stable. Yes, I'm aware that those tests require a running Iris node, but the overhead of ensuring Iris is running is significantly lower than the associated costs of unit tests during protocol updates.

But these are my 2 cents. If you really want to go down the unit test path, I have no objections, but it will be significantly more code to maintain and won't provide added value over the integration tests. But if you do want to do this, please implement it through sockets and don't gut the protocol class. There's no need for it.

[paplorinc]

Managed to separate the communication layer from the higher layer, without "gutting", "littering", "backfire"-ing and other big words.

Implemented the recvVarint and changed the sendVarint to be cleaner, more general and avoid infinite loops. In case you have objections, please let me know. Unfortunately it's still not working for negative numbers (it's one of the reasons why I have extracted the hasNextChunk method, it should probably be extended);

Also, the sendString seems to be limited to ~1000 characters, not sure what's causing that - it might simply be the PipedStreams in the tests.

I designed the send and recieve tests to use the input of one another, so that it won't be a "significant overhead" on protocol update.

If you want to rewrite the tests to use sockets, feel free to do so, though the design and tests are cleaner this way, in my opinion.

[karalabe]

Negative numbers are not needed. Those would require special handling anyway as varints were designed for unsigned only.

I'll look into the string limits in the morning.