Joining the packet sources

[l0udPL]

So you're not planning to physically divide packet-event handling to different files for each protocol? Just implementing some minor differences (to use encyption or not) between two last versions of client in one place? If so, why bother? Is there any real reason to temporary keep older version in use?

[xoft]

They will be in different files - each protocol will be handled by one class, each class in a separate file. I'll be reusing protocol classes by deriving the new one from the old one, thus the new one will only implement the changes.

[l0udPL]

And older class will be eventually supplemented by missing methods intruduced in newer protocols? (doing likely nothing but it's ok) Now it makes sense. It's indeed a good idea - seeing protocol changes between different versions looks very nice!

I'm afraid, I'm too stupid to give you any helpful advice now. I reckon implementing that stuff will take some time, so it would be nice if you'll commit early changes on different branch in svn, even if they'll not work. Especially ssl-related stuff

[FakeTruth]

Sounds pretty cool.

Would it be possible to faze into this new system? So we can be sure it performs as expected (in all ways) before spending a lot of time converting everything.

PS:
I was on vacation in Bulgaria for a week, I forgot to mention that. Sorry

[xoft]

It could be done in a few phases, I suppose. First the utility classes - cByteStream and descendants. These can be used in the current packeting code as well. Then the cProtocol class with 1.2.5 protocol implementation. And finally the 1.3.1 protocol implementation and protocol recognizer.

I was wondering why there was no Truthful reply for some time

[xoft]

One thing has started to bother me now. Currently the client is capable of doing selective packet removal - if there are two packets containing moves for the same entity, the earlier packet is dropped and never sent, because the later packet would invalidate it anyway. This saves (surprisingly quite a lot of) bandwidth. But with the new architecture this would be difficult to maintain. If the command did serialize the packet immediately, it would be impossible to later remove that packet from the stream.

---

The only solution that I can see is to modify the entity move command caller not to emit that command that often - don't move the entity 20 times a second, but only 5 times a second, for example.

---

I take back the importance of this. I've just tried adding some statistics and the RelEntMoveLook packet is currently not optimized away any single time in over 15000 packets sent. True, that's for a LAN session, WAN results may still vary.

[xoft]

Testing on WAN confirmed that this optimization is pretty much useless. On normal ISP-housed servers (on a fast connection) the server didn't drop a single packet in over 10K packets sent. On an extreme server, based on a slow-upload home inet connection and accessed over internet from another location, the server dropped about 40 packets in a 10K, a mere 0.4 %. On a bandwidth scale, this was about 1 KiB saved in about two minutes. That's not worth doing, especially if we can expect the AI to change to a less random one.

I implemented the first stage of the packeting rewrite, now the packets parse themselves from a cByteBuffer object, rather than a raw string. Also, finally the UTF16 strings are being parsed completely correctly (I hope without dropping the high bytes.

[FakeTruth]

It did drop a lot of packets on my server, that's why I implemented that feature :O

[xoft]

Maybe it was in the time when the server was not properly multithreaded and the generator and lighting were slow. This could've caused the outgoing packet queue to grow. Nowadays the packet leave the server almost as soon as they are queued.

[xoft]

Another side-effect detected:
Some cPacket descendants were exported to Lua and plugins were using them, both to send packets and to handle hooks (BlockDig, BlockPlace). These will be removed, so Lua hooks' signatures will change and the plugins will not be able to invoke default behavior with a modified input data. I don't think this matters much, since it was a very under-documented feature anyway and I don't think anyone would be using that in a plugin anyway.
The interface change, though, is not so great. We'll have a new round of plugin incompatibility