Changing to SuperSocket

[ovflowd]

As far i can see, Yupi si leaving DotNetty (sad) and going to SuperSocket.

The fact is DotNetty is really more faster and perfomatic. But is beta, and doesn't work with linux. (yet)

[TheDoct0r11]

I didn't remove DotNetty entirely. I just reduced the coupling and created a library with a common interface. This way (once I complete reimplementing DotNetty) one can choose which Network IO System should be used.

Also if required a new IO System can be implemented without the need to change the upper levels

We might want to do some stress testing once implementation is done.

[Killua99x]

SuperSocket is slow? @sant0ro

[TheDoct0r11]

I don't think that network IO really is a performance bottleneck. To be sure we would obviously need a test site giving us profiling data (Visual Studio as well as mono) but I would guess that we spend the most time with SQL queries...

If Sockets really were a bottleneck a native implementation would be the only solution since both SuperSocket as well as DotNetty probably use the underlying System.Net.Sockets implementation.

[ovflowd]

@TheDoct0r11, putting again the Emulator in Libraries like in Azure? Idk think is necessary. But is good. The public functions names doesn't will change, don't interfering in the Upper API. Also return types and arguments can't change. In the public voids.

I think main problems in Yupi now are:

1. Useless Queries / Security
2. Cache System (Is really bad, and only for items i think..)
3. Threads (badd)
4. Packet System (i improved a lot, removing the xitty delegateds i think)
5. Packets need be necessary synchronous and not asynchronous, because Habbo Client need that. Habbo Client wait the event response, if other thing is answered.. crashes. So for a session (an user) only a single communication job can be in execution in twice time.

SuperSocket is nothing Super, only a better Socket System that the default from C#, but based on default methods from C#. Same as DotNetty

but DotNetty is a transport of Netty to C#, the first complete transport, made by Microsoft Azure developers. Netty is one of the bests Communication Frameworks for Java. Also DotNetty is reactive. That is totally needed and good. And has all native implementations that we need. As you can see the Socket System of yupi with DotNetty is really smallest that from the before one. Also more secure and fastest.

... Also other big problems:

6. Incompatibilities
7. Documentation (major)
8. And a lot of codes that aren't being used or big or extensive.

One of my last current jobs was creating Dynamic Handlers, that means for each Packet we have one Handler, and not a response structure hard-coded directly on the call, and repeat a lot of times. Hard..

In June i will be back. I really need talk with u @TheDoct0r11 through Gitter.im, about jobs, ideas, etc.

Thanks!

[TheDoct0r11]

The separation into libraries isn't really necessary but it can lead to faster builds since only the changed library must be rebuild. Also it enforces better coding structure by hopefully reducing coupling.

Additionally it is a paradigm from the Unix world: One library should only have on task.

Yes, I know that both are based upon System Sockets. And as far as I know Microsoft's socket implementation is asynchronous anyway..

But as I've said, I will keep both around so that linux/mac users can use the supersocket implementation whereas Windows users can choose.

Unless a stress-test proves that one or the other performs better, both should be maintained.

Also since DotNetty has zero documentation and seems to be in an early development state I'm kind of reluctant on using it. (Also SuperSocket has similar problems with a missing implementation for a Setup call...)

But as I've said if we're going to find a better library we can now easily implement it using the interfaces and won't have to change references within the ClientManager...