Link to home
Start Free TrialLog in
Avatar of petoskey-001
petoskey-001

asked on

Help Designing Async Socket Program

I am working on a rewriting a chat program.  It's a peer-2-peer chat program that seeks out new connections as well as listening for incoming connections.  I have a working model in Delphi, but I'm trying to port it to VB.Net and eventually to PocketPC.  I'm just having some trouble with the conversion and figuring out how to do things in DotNet.


The general design is as follows...

1. Startup
2. Launch a few hundred Async connects to clients on a certain port for my current sub-net.   This is only done once at startup.
3. Start listening for incoming connections on a certain port for incoming connections
4. If anything connects to us, or we establish a connection with a remote machine, start a new thread to handle the conversation
5. ASync connections that are refused or timeout are closed


Looking at converting this from the old handles and API calls to DotNet, I plan on having three classes.

* Listener class *
     Listens for an incoming connection on a port, accepts the connection and launches a new Chat thread to handle incoming connections.  There would only be a single instance of this class.

* Connector class *
    Tries connecting to multiple remove machines on a certain port.  If a connection is established, start a new chat client thread to handle incoming connections.  So far I just store this as the Async state, then pull it out again in the OnConnect.

* Chat class *
     Performs actual communications with an established connection initiaed by one of the previous two classes.  
     It will contain a timer to send out keep-alive packets (just chr(255)) every few seconds to let the other end know we're still here

I have written an ASync port/subnet scanner that works well.  I understand that part.  I have made a simple listener that responds with current time.  So far I haven't used any threading, just BeginConnect, BeginSend, etc.  


Q1. What would the best way to design these classes, and do I need to create a seperate thread for each chat client?  Does my current design look alright?
Q2. How do I pass the newly established connection from the connector or listener to the chat class?
Q3. Can I get by with ASync callbacks, or will I need threads for this?

I assume this is one question, but I'll make new question if I must.  
Avatar of petoskey-001
petoskey-001

ASKER

== Project Background, possible useless facts ==
I am working on upgrading a previous handheld project from eVB to VB.Net.  I previously was using the winsock control, but of course that is hopelessly slow.  I rewrote the app in VB6 using winsock then tried using the "Upgrade Wizard" to convert to DotNet but found it was rather pathetic and simply used a VB Compatibility wrapper instead of doing any REAL conversion.  That's just background information for those who would ask.  

All the examples I've seen are console based and never deal with accessing member variables in other classes.  In real life things seem a bit more complicated and I want to make sure I do this right rather then some ugly fragile hack.  

Thanks DotNet experts.
Solved problem myself.  It's way too large to post here, but in general I am using several classes.

The GUI, The Listener, The Seeker, The Chatters, The Updater

GUI Starts
GUI spawns the Seeker to async scan subnet for other devices to connect to.  If connection is established, a Chatter is spawned.
GUI spawns listener
Listener spawns Chatters
Chatters put all incoming data into a queue
The Updater reads the queue and updates the GUI with synclock to make sure multiple connections don't step on each other.

Handles about 20 PocketPC's talking to each other at the same time without a problem.  Scans whole subnet every few minutes for other compatible programs.  All happens Async using thead pooling.  Lets everyone edit the same text document at the same time.  

Sockets are passed using the socket from BeginConnect / EndConnect or BeginListen/EndListen

I don't know if this is the best way or not, but it works and causes very few exceptions that are handled.  It seems to be clean code and the number of clients scales with resources not some arbitrary limit, so I guess it works.

ASKER CERTIFIED SOLUTION
Avatar of modulo
modulo

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial