BrickEmulator [C#] Pooling Sockets + From Scratch

[Shredinator]

love you both

[AresCJ]

Someone already tried to DoSs x]

Isn't that like a simple few lines of code?

[wichard]

Isn't that like a simple few lines of code?

Ye duh.

[vLife]

Funny thing about the DoS, the person openly admitted it.

[1ntel]

A DoS isn't going to test your server stability lol. You also can't block DDoS from within the program btw, you need proper firewall / mitigation service for big DDoS.

[Jaxite]

A DoS isn't going to test your server stability lol. You also can't block DDoS from within the program btw, you need proper firewall / mitigation service for big DDoS.

Finally someone who speaks the truth around here.

This development seems good, and I expect it will be a well used server upon its release.

[1ntel]

You really need to change your packet handler though Wichard. Initializing a handler per user is pointless and slow.

[Mikas17]

Bug Report:



Good luck with the project

[vista4life]

You really need to change your packet handler though Wichard. Initializing a handler per user is pointless and slow.

hmm true do you have any examples todo it ? i'm behind your idea your totaly right.

[1ntel]

hmm true do you have any examples todo it ? i'm behind your idea your totaly right.

Make a global message handler and message composer handler (if you want to do it that way) then initialize all handlers into a global handler which takes the parameters Session and Client Messages.

Then route all users through the global handler when an incoming message comes in, don't use any locking as this will kill performance on anything globally accessed!!! and don't share any global variables inside the handler classes, this will cause race condition errors.

I store all events on server bootup into a dictionary and access them by header packet ids.

public void HandleEvent(uint HeaderId, Session Session, ClientMessage Message)
        {
            IMessageEvent Event;
            if (_Events.TryGetValue(HeaderId, out Event))
            {
                if (!Session.Authenticated && HeaderId != 206 & HeaderId != 415)
                {
                    Console.Write("Un-authed packet received " + HeaderId);
                    return;
                }

                Event.Parse(Session, Message);
            }
            else
            {
            }
        }

My code still needs finishing and cleaning up, but that is just a quick example.

Anything inside the "Parse" function of Events is thread-safe as each Thread aka connected user/session creates its own stack, so it is thread-safe and extremely quick. Quick because events are accessed by index id's aka the header id's.

So that is basically it :-)

[NoBrain]

Why does everyone always use Public & Private when Internal is clearly better ^^

[1ntel]

Why does everyone always use Public & Private when Internal is clearly better ^^

because Internal is used for different means. Internal is visible in the same assembly, not namespace where as public is visible in the same namespace.

They both have different means, same with protected vs private, there is no such thing as "clearly better", they just restrict visibility to certain things.

I always forbid using public on any shared variable, I prefer to make everything private and access shared variables through a get set property. I use sometimes auto propertys which i use via "public ClassName aNameHere { get; private set; }" which can be quite useful, makes the compiler auto-generate a private variable which is accessed by a get set property.

[NoBrain]

Isn't internal stabler or something? I read about it somewhere...

[wichard]

You really need to change your packet handler though Wichard. Initializing a handler per user is pointless and slow.

NOOOES, i got 1 Packethandler global that interacts with an void.

[1ntel]

NOOOES, i got 1 Packethandler global that interacts with an void.

Good man ;).

---------- Post added at 12:43 PM ---------- Previous post was at 12:42 PM ----------

Isn't internal stabler or something? I read about it somewhere...

No they are just access modifiers, there is nothing more stable or faster about the word internal. If it was that magical I would of thought Microsoft would of done whatever 'magic' internal does to the word 'public'