Jump to content
  • Advertisement
Sign in to follow this  
Stukey

[.net] Async Sockets Questions

This topic is 4842 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

You can find the full socket source here for the questions I am asking. I read this page about how it is supposed to work and it didn't help me very much which is why I still have these questions. 1. All other examples i've seen have have declared a private socket for the class, but in this one all of the sockets are inside methods, doesn't this mean a new connection will have to be made everytime data is sent/recieved? 2. I thought this is supposed to be non-blocking, but there is a "While" loop in it that appears to block until a connection attempt is made, am I missing something? 3. The code of acceptCallback is explained in the site, basically by saying "This is what you do", I'm just wondering why you have to dim 2 more sockets to point to objects you converted off of some parameter I also can't find an explaination for. If these questions get answered I will probably have more because I'm hopelessly lost... thanks [edit] Also if someone could just make a simple nonblocking tcp socket in visual basic .net or tell me where I could find an example that would be equally helpful, A thought also is would it be impractical to have a thread for each socket and just use the premade blocking tcpclient objects in .net if i wanted to support a max of maybe 100 connections on a server? [Edited by - Stukey on August 18, 2005 1:40:13 AM]

Share this post


Link to post
Share on other sites
Advertisement
First of all, only after writing this post did I notice that you are actually using VB.NET, so there may be some code that is C# in this post.

1. Well, if you look closely at the source, you'll notice that it retrieves the socket object in the read handler with this code:
StateObject state = (StateObject) ar.AsyncState;
Socket handler = state.WorkSocket;

But you are still right, this example seems to assume that you are just handling one request that you will receive on the socket. Normally, you'd definitely store your sockets somewhere (although I'd use TcpClients instead, but whatever).

2. Again, I am pretty sure they used that just as an example to also show the usage of ManualResetEvents.. Obviously, there's no need at all to do it this way, you could just as well call BeginAccept again after having received a connection.

3. I guess this may look weird, but if you look at the documentation, it's actually not so much.
Socket listener = (Socket) ar.AsyncState;

This works because AsyncState will contain whatever you pass to BeginAccept as the last parameter, so not a lot of magic involved. So basically, this is just the original socket on which you are listening for new connections. EndAccept will just give you the socket for this new connection, that's why you have two sockets in there.

In my opinion, all this isn't really that hard once you get used to it. It takes care of a lot of things that you'd have to do yourself if you want to use blocking calls in separate threads yourself. If you do decide you want to do that, just take a look at the System.Net.Sockets.Socket class, it has simple Listen, Receive, Send etc. methods that you can use for this purpose.

Hope this helps. :) Either way, 100 connections shouldn't be any problem at all.

Share this post


Link to post
Share on other sites
Thanks, for some reason I was too wrapped up in being lost to understand the parameter thing, helps a lot. I'll try it out and probably be back when I fall on my face again.

[edit] fairly unrelated but...
Dim bytes() As Byte = New [Byte](1024) {}

why the [] around byte, and why the {} at the end, New Byte(1024) is what I would put and I'm curious if that is bad in some way.

[Edited by - Stukey on August 18, 2005 5:16:19 AM]

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!