[Open Source] SlimIOCP - Library for building high performance TCP socket servers

As the need for having access to both TCP and UDP arose in my server software (SlimNet) I started developing a library called SlimIOCP (IOCP stands for I/O Completion Ports which is a technology for doing high performance I/O, including sockets) which handles the low level TCP plumbings (sort of what Lidgren does for UDP, with the added benefit of the TCP layer being a lot smaller due to the inherent QoS guarantees of TCP itself)

While IOCP as a technology is only available on windows the plan is to use GIO (GIO-Sharp for mono) or some other type of similar tech that has Mono bindings for Linux.

Anyway, since this is not a "trade secret" piece of technology in my server, I decided to open source it, you can find it at over at github: https://github.com/fholm/SlimIOCP.

Might be the perfect library for someone that needs to build a non-action based project like an MMO, Turn-Based or RTS style game.

Edit: The library is not done, but it is working and pretty solid, major things to implement is the Mono Client and better error reporting in the server

 

Thanks man,this is cool!

 

but how about lidgren ?

and where can we visite the forum about SlimIOCP ,just like lidgren .

 

Lidgren is an UDP library, if you're asking in terms of SlimNet then there is a configurable option that will allow you to switch between TCP (using SlimIOCP) and UDP (using Lidgren).

If you're asking in general why create another library when Lidgren exists? As I said ligren is an UDP library, this is a TCP library - they target different types of games.

 

nice. It looks like a decent slim implemention. Right out of the text book from msdn.

However why are you using var all over the place? Its not good csharp coding practice. I'm sure the compiler will fix it for you, but its like compiling with warnings... something that can hide subtle bugs.

The people who needs IOCP is the people making multiplayer games... to write a multiplayer game with abundant use of the var keyword or code warnings... Well there is a reason why its not best practice and thats cause the code may look right, but not do what you intended.

Again nothing wrong with using var statements in your code, for script interaction or Linq expressions. But its just sloppy and dangerous in core libraries. (And yes I know even mmo's have been written in script languages that only supports var equivalents. But I can guarantee you that weeks have been lost hunting obscure bugs hidden by this.)

 

You do know that all "var" keywords are statically compiled to their proper type? There is no dynamic runtime typing, it's all resolved at compile time and statically checked for you. Same as let in F#, etc.

I use var because it looks cleaner and is easier to read.

Edit:

It also does a fair bit more then the base examples on MSDN, like being fully generic and supports any socket backend, not just the IOCP backed SocketAsyncEventArgs

 

well proper type... it might be int, it might be double... when its later multiplied by a double the end result will certainly be double... I didn't say I saw anything wrong with this code, but when bug fixing in code I do prefer all types to be spelled out for me, rather than having to read it back to its source and determine it. I have seen people apply a "bug fix" and assuming stuff about the type thus creating a whole new problem.

As for the reference to msdn, I didn't mean that you copied the sample in any way... if you or anyone read it as so I apologize! The msdn sample only shows the technology. It doesn't have the neatly wrapped read thread. It supports only raw streaming, it doesn't have a message layer on top. So clearly this is a vast improvement and a solid base to build on. Thats why I think the liberal use of var is unfortunete... cause you built something good!

I meant it when I said: nice. It looks like a decent slim implemention. Right out of the text book from msdn.

Indeed I would have preferred to see this sample on msdn than the one I actually found there.

 

And you can just hover the variable in VS, etc. to see type if it at any point is unclear.

And sorry if I came of a bit harsh in my first response, re-read it now, it was not my intention

Edit: I realized you probably mean that the type of "var" can change without you realizing it when editing the code. Which is true, might be reason enough for me to change it to static declarations for this type of library actually.

 

Lets not derail this thread any further.