What if we receive half a position?
Multiple position in a single frame/message is common. Frame decoder is there to make sure each frame is separate and complete. It has nothing to do with multiple positions.
i see what what you mean,
so in one frame we can have multiple positions..
so the remained question is how is it possible that we receive a "half position"
or a package that has one full "frame" and a remaining of half frame ?
usually devices are sending data in a complete package, at least this is what i saw in ruptela and teltonika
so i don't understand how can we get a half position?
or all this is just to avoid some rare cases, where somehow in the network layer (tcp / buffer reader etc..) we got a multiple packages into the same buffer when we start reading from it
It is there to properly handle TCP. It's pretty common for TCP to combine multiple small message or break up large messages, so it's not really a rare case.
well, amm, feels like netty should handle it, isn't ?
i'm not that familiar with netty but this is what i was expected from a framework that support to handle network messages..
to give us a clean packages .. no matter if they got break /marge in the other network layers
If you really want to have a productive conversation here, please do some research first. First of all, TCP is a steaming protocol. Netty wouldn't know where one message ends and another starts. The only way to know that is by looking at application level protocol for each specific device, which obviously out of scope for Netty. Seems like you don't really understand TCP and how it works.
well, I may have some lack in understanding, and I'm always happy to learn
the fact is, that i'm running ruptela and teltonika devices more then a year using vert.x framework(which is based on netty)
never facing any issue like you mentioned.
You are right with your point about the streaming..
i'm not argues with you, and you properly have a lot of experience in this part..
i just curious to know how come that i never had any issue like that and i'm not using a "frame shape" like yours
It might work 99.9% of the cases. Or it might fail only is some specific scenarios. That's just the right way to do it to make sure it works correctly 100% of the time.
ok, good to know..
thank you for your answer
Hi all, I just tried to understand to purpose of the BaseFrameDecoder (and his derivatives)
why do we need to split the buffer if anyway in the "position" decoder we first count the number of records and then start parsing it one by one
which at the end the parser return a list of positions.
so it feels like one of the two approaches are not necessary, because anyway if we use the frameDecoder we then received one position each time we parse the buffer..
what do i missing?
note* i'm referring to Ruptela and teltonika protocols, which are the once i'm using
thanks