What about coding an efficient socket system?

I want to start a new project from scratch, and I thought about using my sockets from my last unfinished projects until I saw the .NET 3.5 methods. What do you guys think about the methods used in the sample which was released by MS? I`m talking about the BufferManager approach, and the pool for the SocketAsyncEventArgs. It seems nice to me, I implemented this in my project, with some modifications to fit my needs, what do you guys think about it?

#edit : Also, would it be better if I coded the sockets in native?

Does not matter really, Just use Async sockets. Easy to work around I'm learning to use those as well.

Lol, that`s not what I`m talking about. This sample uses a buffer that is allocated for all users, and every user is granted a 'piece' of it. This seems a good method for me, as you don`t have to create new buffers for everyone, even if it limits the amount of users. You don`t have to allocate dynamic memory for everyone, you have one large buffer.

Just tryed to say something smart :) I'm not the best in that area as I've just started learning all this buffer, static buffer shit, :)

Quote:

Originally Posted by Eliminationn Does not matter really, Just use Async sockets. Easy to work around I'm learning to use those as well.

Made me giggle

Quote:

Originally Posted by EmmeTheCoder Made me giggle

And your point related to the topic would be...?

You have 1 or 100 clients and you will use the same memory. A bit stupid to allocate like 100MB for 1 client... I think it's better in a way to allocate a little 2MB for each client. Something like this.

Even 2 mb is too much

Anyways imho best way is dynamically allocating memory per client.

But dynamic memory is allocating memory from the heap, right? And allocating memory from the stack should be faster.

Speed difference is too small, anyhow that won't be an issue because if i'm not mistaken you're going for managed which is slow enough anyway..

On the other hand if you're going for native then you could do better mem. managing by implementing a mem. pool.
And if you're aiming for top notch performance/speed consider writing it for linux/unix, check out beej's guide for a crash course.

Each connection should have its own buffer if your using sockets, its much easier to manage. One of the main bottle necks is where you split up the packets to be handled so make sure that aspect is small, simple and very efficient.

For the buffer btw, since your dealing with the client's packets you dont need a big buffer, so you can happily allocate 2048 bytes and have done with it without worrying about incomplete packets due to filling the buffer, because you'll never fill it.

Quote:

Originally Posted by Nullable Even 2 mb is too much Anyways imho best way is dynamically allocating memory per client.

I know. In general, I allocate between 1 and 3 Ko. Depends of the protocol.

Quote:

Originally Posted by Korvacs Each connection should have its own buffer if your using sockets, its much easier to manage. One of the main bottle necks is where you split up the packets to be handled so make sure that aspect is small, simple and very efficient. For the buffer btw, since your dealing with the client's packets you dont need a big buffer, so you can happily allocate 2048 bytes and have done with it without worrying about incomplete packets due to filling the buffer, because you'll never fill it.

Possible that it would fill in the case of someones net dropping and then coming back before they time out (of course depends on the time they've dropped and how much data they would've sent in that time). Unlikely, and as long as you have proper checks you can drop someone who lags that bad.

Quote:

Originally Posted by _tao4229_ Possible that it would fill in the case of someones net dropping and then coming back before they time out (of course depends on the time they've dropped and how much data they would've sent in that time). Unlikely, and as long as you have proper checks you can drop someone who lags that bad.

TQ has a packet for the lag. Just nobody use it.

Quote:

Originally Posted by CptSky TQ has a packet for the lag. Just nobody use it.

Which packet?