Can someone better explain Decoders/Encoders?

Question

Revised Question:

Ok so I am trying to incorporate this in my own custom made game. I understand the process of how Netty Servers and Clients connect. I also understand how the decoders and encoders work in theory. But here's what I still would like to understand.

My server process:

Server boots up -> Client starts
Client requests connection -> Server accepts
Server instructs client connection is good -> Client continues to the login screen
(Ignoring any type of security protocol)
Client sends username and password over Channel
Server gets username and password checks it in the database or file
Server pushes -> yes or no
if yes Server sends player stats
if no Server creates new player

After that process I know I need to have a world handler so that everyone is seeing updates in near real time. Now I don't know how to implement decoders for this stuff.

I really would like to see some examples with some explanations of how they are implemented. with preferably some instructions.... Note: I am not saying solve this issue for me but show me how to handle the different information. Best practices and standards please....

Answer 1

People write their own encoders/decoders (codecs) because Netty doesn't impose nor define an application level protocol, so that you are free to write your own protocol. The set of codecs you define is a protocol that can be anything between String based and some binary format as Protobuf, for example. Netty provides codecs for your convenience (the ones you used are examples).

I would assume this is to keep the stream from being cutoff early?

Usually, when you are sending/receiving streams, you need to decompose that on a fixed length chunks (called frames). A popular approach, that has been used since the dawn of the Internet, is to use the length of the chunk (usually a 4 bytes int) as the first field read from the stream. So if the value of the first int is 20 then you know that the following 20 bytes are the payload (the data), and the 21th byte is the first byte of another length. The advantage of this approach is that it allows chunks of variable length. But you are not limited to this. For example, if you plan to write a protocol that uses Strings with predefined length (with padding) then you'll write or, even better, use Netty current codecs appropriate to it.

Once, I implemented a protocol with three decoders that would perform in this order:

1. receive a stream and decompose it in length prefixed frames;
2. convert each frame to a string;
3. use Jackson libray to convert a string to a predefined Java object.

The encoders would just do the same operations, but backwards. Unfortunately, I've lost the original code, but I will rewrite it soon.

But how does the stream know that the stream is a String or a series of int's or a series of doubles? How do you tell it the difference is the question?

Short answer: it doesn't know. You have to encode this info in the codecs. For example, you can use a opcode as the first field in the payload that says that payload are Strings, doubles, ints or any combination of both.

Basically, Netty provides a stream and you are free to decode as you like. For example, if you are reading a series of longs (8 bytes) then you are going to write a codec that reads 64 bytes at a time from the stream because each one represents a single long. Netty provides codecs out-of-box so that you don't need to reinvent the wheel every time.