[Killpot]

Yo.

So I was bored, and always wanted to really figure out how DragonHunter's LiteCode worked, so I tried to make a watered down version that is much more lightweight and easy to understand.

The idea is that when the client connects to the server, the server will initialize a unique SharedClass for that client, the client can then call those functions in its persistent session as it feels and never know what's actually happening in the methods!

Now I'm aware that creating a strongly typed method only to pass it to a generic method is redundant, however, combined with a DLL that contains the Prototypes, it makes syncing up the server's SharedClass with the client very easy. I was planning to do it another route instead of manually create overrides for the Prototypes interface, however, that required Emitting OpCodes and a lot of really complicated shit for a not very difficult task, and in the end this was the best method I could come up with that was still simple, however it does come at the cost of speed.

Features:
- Remote Execution
- Event Driven (Minimal RAM/CPU Overhead)
- Elliptical Curve Diffie-Hellman Handshake
- AES 256 CBC Encryption + Random IV + HMAC Authentication
- GZip Compression
- .Net 3.5 (Could prob get lower if you remove ECDH Handshake & LINQ)
- Dynamic Incoming Buffer Size (I don't know why everyone uses static buffer sizes, I'm coming HeartBleed! :* )


GitHub: https://github.com/Icemantheditor/NotLiteCode

[hybris.softwares]

Hello,
This is a pretty neat release, however i've found some things i would do in another way. I might do a push request later to github.

1) The AES_Encrypt and AES_Decrypt methods could be moved inside the sClient struct for 2 reasons : First you could initialize your aes engine one time per client and store it in a field to reduce overhead in initializing and disposing it.


2) You could avoid using MemoryStream by using :

Code:

using(ICryptoTransform encryptor = AES.CreateEncryptor()) { encryptedBytes = encryptor.TransformFinalBlock(bytesToBeEncrypted, 0, bytesToBeEncrypted.Length); }

3)You could use an enum backed by a byte to send headers

Code:

enum Headers : byte { HEADER_CALL , HEADER_RETURN, HEADER_HANDSHAKE, HEADER_MOVE, }

This way you could improve the packet structure.

Regards,
Hybris Softwares

[Killpot]

Hello,
This is a pretty neat release, however i've found some things i would do in another way. I might do a push request later to github.

1) The AES_Encrypt and AES_Decrypt methods could be moved inside the sClient struct for 2 reasons : First you could initialize your aes engine one time per client and store it in a field to reduce overhead in initializing and disposing it.


2) You could avoid using MemoryStream by using :

Code:

using(ICryptoTransform encryptor = AES.CreateEncryptor()) { encryptedBytes = encryptor.TransformFinalBlock(bytesToBeEncrypted, 0, bytesToBeEncrypted.Length); }

3)You could use an enum backed by a byte to send headers

Code:

enum Headers : byte { HEADER_CALL , HEADER_RETURN, HEADER_HANDSHAKE, HEADER_MOVE, }

This way you could improve the packet structure.

Regards,
Hybris Softwares

Thanks for the response, as to 1: wouldn't that consume more RAM overhead as you would be storing an additional class for each client? As to 2: I really didnt take much time to look at the encryption, was just some cookie cutter I found on stack overflow, I'd like to get an AES GCM class in there but I'm not aware of how to do it without a third party lib. And for 3: That's what I was doing, however it had problems with that method as the bytes wernt serializing correctly, I plan to come back however and see if I can fix it.

[Killpot]

Repo has been updated, It's now using AES-NI for hardware acceleration, as that's the only real bottleneck between 30 messages a second and 15k a second. I've also changed the way functions are called so you don't have to rely on the name of the function, now you can add an identifier to your function inside the SharedClass, and the client will call the functions based on that Identifier. Also, fixed some serialization issues. And as to Hybris who suggested using an Enum, that's not going to be possible with the way I'm doing things, Serializing with a BinaryWriter includes metadata, so when I deserialize on the server it will try to cast it to the sender's variant of the Enum, and obviously not work. The solution to this would be to either just send raw variables, or use a centralized DLL. I also plan to create an encryption class instead of using functions, as the performance boost will be noticeable, whilst the negligible increased RAM overhead will not.

[hybris.softwares]

Repo has been updated, It's now using AES-NI for hardware acceleration, as that's the only real bottleneck between 30 messages a second and 15k a second. I've also changed the way functions are called so you don't have to rely on the name of the function, now you can add an identifier to your function inside the SharedClass, and the client will call the functions based on that Identifier. Also, fixed some serialization issues. And as to Hybris who suggested using an Enum, that's not going to be possible with the way I'm doing things, Serializing with a BinaryWriter includes metadata, so when I deserialize on the server it will try to cast it to the sender's variant of the Enum, and obviously not work. The solution to this would be to either just send raw variables, or use a centralized DLL. I also plan to create an encryption class instead of using functions, as the performance boost will be noticeable, whilst the negligible increased RAM overhead will not.

Using a static class is good enough.
My approach was to just cast the enum value to byte before serializing them and on the client cast them again to header enum.

Regards,
Hybris

[Killpot]

Repo has been updated, It's now using AES-NI for hardware acceleration, as that's the only real bottleneck between 30 messages a second and 15k a second. I've also changed the way functions are called so you don't have to rely on the name of the function, now you can add an identifier to your function inside the SharedClass, and the client will call the functions based on that Identifier. Also, fixed some serialization issues. And as to Hybris who suggested using an Enum, that's not going to be possible with the way I'm doing things, Serializing with a BinaryWriter includes metadata, so when I deserialize on the server it will try to cast it to the sender's variant of the Enum, and obviously not work. The solution to this would be to either just send raw variables, or use a centralized DLL. I also plan to create an encryption class instead of using functions, as the performance boost will be noticeable, whilst the negligible increased RAM overhead will not.

Using a static class is good enough.
My approach was to just cast the enum value to byte before serializing them and on the client cast them again to header enum.

Regards,
Hybris

Your ideas would I guess work in a scenario where you're only handling a few clients, but if the server is handling high loads of clients efficiency is going to be everything, and re-initializing that Aes Crypto provider for every message sent to the server could hog a ton of CPU usage. And why cast the enum to a byte every time when you can just statically declare a byte? Seems like an extra step just for the sake of using an enum.

---

Repo has been updated, It's now using AES-NI for hardware acceleration, as that's the only real bottleneck between 30 messages a second and 15k a second. I've also changed the way functions are called so you don't have to rely on the name of the function, now you can add an identifier to your function inside the SharedClass, and the client will call the functions based on that Identifier. Also, fixed some serialization issues. And as to Hybris who suggested using an Enum, that's not going to be possible with the way I'm doing things, Serializing with a BinaryWriter includes metadata, so when I deserialize on the server it will try to cast it to the sender's variant of the Enum, and obviously not work. The solution to this would be to either just send raw variables, or use a centralized DLL. I also plan to create an encryption class instead of using functions, as the performance boost will be noticeable, whilst the negligible increased RAM overhead will not.

Using a static class is good enough.
My approach was to just cast the enum value to byte before serializing them and on the client cast them again to header enum.

Regards,
Hybris

Your ideas would I guess work in a scenario where you're only handling a few clients, but if the server is handling high loads of clients efficiency is going to be everything, and re-initializing that Aes Crypto provider for every message sent to the server could hog a ton of CPU usage. And why cast the enum to a byte every time when you can just statically declare a byte? Seems like an extra step just for the sake of using an enum.

[Killpot]

Just pushed out another update that will hopefully tackle the client's shared class disposal when it disconnects.