Discussion on [Release] SocketSystem using SocketAsyncEventArgs within the CO2 PServer Guides & Releases forum part of the CO2 Private Server category.
Its just a base, you can implement it on MANY ways....
I removed my implementations and let just the working base,
The socket works very well... and i tested it for some good time...
As example i created my self, a account server .... for version 4351 (it still work to 5095 versions tho....)
Good luck, and i'd like some good feedbacks ....
EDIT: Some advices for implementations would be creating a buffermanager and the socketasynceventargspool to reuse the eventargs, that increases the speed when receive or send data to client, since you just change the UserToken and you'll not recreate the buffer, just overwrite the old one.... there are a few samples on internet.... you can just google to see some more interesting things :]
Just out of curiosity (I'm not home, so I can't see your code), what's the benefit of using SocketAsyncEventArgs? What're you using it for to make this socket system special? Or, are you just releasing a socket system, period?
That's what i have studied so far....
If you use the APM pattern (Begin/End methods), each and every BeginSend and every BeginReceive allocate an IAsyncResult instance. This means there's a full class/object allocation occurring roughly 10,000 times per second (500*10 [send] + 500*10 [receive]). This puts a huge amount of extra overhead in the system since it's going to add a lot of GC pressure.
Switching to the new suggested method for high performance networking applications, you'd preallocate the SocketAsyncEventArgs instances (500) and reuse them for every method call(like i said, creating a pooling system for them), thereby eliminating the GC pressure created during these operations.
That's what i have studied so far....
If you use the APM pattern (Begin/End methods), each and every BeginSend and every BeginReceive allocate an IAsyncResult instance. This means there's a full class/object allocation occurring roughly 10,000 times per second (500*10 [send] + 500*10 [receive]). This puts a huge amount of extra overhead in the system since it's going to add a lot of GC pressure.
Switching to the new suggested method for high performance networking applications, you'd preallocate the SocketAsyncEventArgs instances (500) and reuse them for every method call(like i said, creating a pooling system for them), thereby eliminating the GC pressure created during these operations.
I had two or three different types of socket wrappers for my older sources. The first one I ever did was rather simple. I had a ConcurrentDictionary<string, EndClient> (EndClient was my client class.), the string key was the RemoteEndPoint in string form (i.e. 127.0.0.1:62843), which of course was unique for each connection, and it pointed to the value (the EndClient). Upon receiving I would check if the dict contained the REP (RemoteEndPoint), and if it did, grab the EndClient that matched the REP for local use, check if the socket is connect, char isn't null, etc, and then process the packet. Pretty simple I guess. I've always used some kind of client pool, as well as pools for things like guilds, teams, monsters, etc. I never believed in assigning a reference or whole new copy of each guild/team to each character instance, because it didn't make sense to me. Simply assign the guild ID/team ID to the character, and when you need the guild/team instance, check the guild/team pool for that ID! I hate when people do silly things like assign whole classes to their character class when it's obviously not needed.
That's what i have studied so far....
If you use the APM pattern (Begin/End methods), each and every BeginSend and every BeginReceive allocate an IAsyncResult instance. This means there's a full class/object allocation occurring roughly 10,000 times per second (500*10 [send] + 500*10 [receive]). This puts a huge amount of extra overhead in the system since it's going to add a lot of GC pressure.
Switching to the new suggested method for high performance networking applications, you'd preallocate the SocketAsyncEventArgs instances (500) and reuse them for every method call(like i said, creating a pooling system for them), thereby eliminating the GC pressure created during these operations.
Any evidence of this? After searching for quite a while i found 1 reference that states that switching from this to ReceiveAsync/SendAsync reduces GC overhead like you say, but nothing that says theres a problem in the first place.
Edit: Btw i agree with your decision to use XAsync methods instead of the typical XBegin/XEnd methods, always good to see improvements on code.
@Zeroxelli
I did not mean that you used or w/e heh.... it was just a simple explanation and i guess you understood it pretty well... Ftw by using this sort of socket system you don't really need to create a pool for connected client sockets (i mean client sockets, not user...) since its already created at the socketpool, but you can yet use a list our w/e to set the recent connected clients, to prevent problems like the old impulse's source had if i'm not wrong you could connect 2 clients and keep duplicating cps or things like....
I just wanted to show an implementation of the xAsync to the pservers... sure that's not the BEST one, but you can always use Google to search for new things.... there are alot of samples of sockets using SAEA... also it would bring some new views for who wants to learn more than just coding for pservers ;P
Anyway thanks for feedbacks and i'll take whatever you guys say to implement it hehe.....
//EDIT: Don't worry about... and i agree with u.... there's a point on just search for the already created objects(teams,guilds,etc...) and if you have checked EOsource or if you didn't... check it... its a great resource
@Korvacs
Yeah the APM pattern doesn't have a problem.... since the GC will always free the memory after use.... but since you have better ways of working with it, and SAEA have a better performance for high performance codes.... why not use hehehe
Also thanks for the feedback ;P
The idea were not a faster connection, but a better performance for the server program.... And the difference with the latency can be tolerated (i my opinion... so use it as you wish :P)
also thanks for the feedback ;P
//EDIT: The released socket is not implemented with the SAEAPool and the bufmanager.... they help a bit, since everything is pre-created instead of create just when there's a connection comming ;]
At the end of the day, there's not all that much that you can do to make things with sockets "faster" as long as you handle them correctly. But if you do find an implementation that seems to work faster for you, by all means, use it.
Good work regardless, 12tails. It's nice to see releases like this in the community, regardless of what the majority think, as it is, after all, quite helpful to newbies.
The idea were not a faster connection, but a better performance for the server program.... And the difference with the latency can be tolerated (i my opinion... so use it as you wish :P)
also thanks for the feedback ;P
//EDIT: The released socket is not implemented with the SAEAPool and the bufmanager.... they help a bit, since everything is pre-created instead of create just when there's a connection comming ;]
Better performance for a server. Having a good ping isn't part of a good server? I don't consider a socket system efficient when I have 200-250 ping in local with some peak to 900. I have 30-50 normally. Memory is cheap. I prefer using more memory and put more pressure on the GC to get a lower ping. Players prefer that. If it can be optimized to use less memory and etc without creating a big latency, I'll say that it's a better socket system.
Anyway, that's an interesting implementation as there isn't a lot that use these Async methods, but I prefer the standard Begin/End async. Plus, as Korvacs pointed, there isn't much comment about the pressure and the recommendation of using Async over Begin/End async.
N.B. A high performance server wouldn't use a GC at all and would control all the memory. I always tend to use C++ for high performance thing, mixed with C++/CLI or C# for the GUI. (GUI without caring of memory management is really nice)
Valid point about a server not needing to use the GC if it's "high-performance". But, good luck getting that with C#. If you're really after the "fastest" option possible for a server, use C/C++ or ASM (if you're feeling daring enough to write a socket library in ASM)
Valid point about a server not needing to use the GC if it's "high-performance". But, good luck getting that with C#. If you're really after the "fastest" option possible for a server, use C/C++ or ASM (if you're feeling daring enough to write a socket library in ASM)
A C++/CLI DLL that will wrap the WinAPI sockets in a managed class that you call in C#. The use of the GC will be minimal.
Thats quite sure, the faster the answer, the better.... But everyone has his/her methods to do the things....
But hmmm.... The idea is to show that there are other ways of doing the things..... so you (anyone who wants to learn) just need to search..... i found alot of good threads about things that i'd never think haha
@CptSky
But about the ping thing..... the maximum i get is 70 using local connection, with an external i'm reaching 300-400....
![[Release] SocketSystem using SocketAsyncEventArgs](https://www.elitepvpers.com/forum/iconimages/co2-pserver-guides-releases/release-socketsystem-using-socketasynceventargs_ltr.gif){kind=small}
