Asynchronous Socket Client class problem

[Matthew King]

Hi all

I've written a asynchronous socket client class, but i've found that in order to consume it I have to use events, and cannot simply for example

SocketClient client = new SocketClient(110, "some.server.com")
client.Connect()
client.SendData("Hello World")

Instead I have to wait for the async method to raise a Connected event, and call client.SendData from there, for complex chains of operations this because a nightmare chain of events

I tried using a manual reset event as on the microsoft example to halt the return of my Connect method until the asynchronous callback had completed, but this blocks the UI

Microsofts example:
http://msdn.microsoft.com/library/de...ketexample.asp

blocks the UI as far as I can tell when consuming the class. Although it says it doesnt

So my question is, how can I use my asynchronous socket client like above, intead of having event chains? I believe using ManualResetEvents is the way except I can't make it work without blocking, Unless I do the following

SocketClient client = new SocketClient(110, "some.server.com")
Thread connectThread = new Thread(new ThreadStart(client.Connect))
connectThread.Start()

Is that the way that I must handle this? if so how do I dispose of the thread properly when it has completed? This poses the problem of not knowing when the thread has completed its job

Using synchronous sockets isn't really an option because its for a POP3 Client, and there will be alot of receiving large messages etc

Id appreciate any ideas on this,
Thanks
Matt.

[Chad Z. Hower aka Kudzu]

=?Utf-8?B?TWF0dGhldyBLaW5n?= <ma**@intervisionsoftware.com> wrote in
news:10**********************************@microsof t.com:

I've written a asynchronous socket client class, but i've found that in
order to consume it I have to use events, and cannot simply for example:

SocketClient client = new SocketClient(110, "some.server.com");
client.Connect();
client.SendData("Hello World");

Instead I have to wait for the async method to raise a Connected event,
and call client.SendData from there, for complex chains of operations
this because a nightmare chain of events.
Yes it is! What you describe is blocking vs non blocking. This is an old
article but describes what you are talking about:
http://www.swissdelphicenter.ch/en/showarticle.php?id=4

You should consider switching to blocking sockets, they are much easier to
use and less bug prone.

You can do this in the native .net sockets, but the methods are quite
limited. You should consider Indy, which is free and supports many more
methods and protocols.

http://www.indyproject.org/
Using synchronous sockets isn't really an option because its for a POP3
Client, and there will be alot of receiving large messages etc.

Just put the blocking sockets in a thread. Its much easier to manage than
async sockets.

Trying to do what you want "blocking" with non blocking sockets will only
create a big tar pit.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

[Matthew King]

Thanks for the reply Chad Z

So if I change say my Connect method to be syncrhonous and I start the connect method on a thread start, how do I know when its complete? set an AutoResetEvent? and if Im calling

Thread thread = new Thread(new ThreadStart(client.Connect))
thread.Start()

Can I somehow pass params to the connect function

Is there any way to encapsulate the threads within the class, so the consumer doesn't have to worry about it

Thanks
Matt

[Chad Z. Hower aka Kudzu]

=?Utf-8?B?TWF0dGhldyBLaW5n?= <an*******@discussions.microsoft.com> wrote
in news:00**********************************@microsof t.com:

So if I change say my Connect method to be syncrhonous and I start the
connect method on a thread start, how do I know when its complete? set
an AutoResetEvent? and if Im calling:

Thread thread = new Thread(new ThreadStart(client.Connect));
thread.Start();
You are still thinking like async - if you change to blocking you know it
connected when the connect call returns.

Even though that article I posted was old and for Indy the concepts still
apply. Did you take a gander at that?
Is there any way to encapsulate the threads within the class, so the
consumer doesn't have to worry about it?

The thread is a class. I dont have any .net threaded examples yet, but we are
working on porting them. Threading a blocking socket is a lot cleaner, as
well as easier than a non blocking socket.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"