Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Asynchronous Socket v.s.Synchronous Socket w/ own thread

1 view
Skip to first unread message

Alan Cabrera

unread,
Apr 17, 2003, 12:09:28 AM4/17/03
to
What are the advantages of an asynchronous socket v.s. synchronous socket w/
its own thread?


Regards,
Alan


User

unread,
Apr 17, 2003, 12:20:57 AM4/17/03
to
It seems to me that with Threading, you can spawn off execution
threads (each with new instances of required classes) and then
have the dotnet/os scheduler juggle them.

With asynchronous sockets, you have to do more juggling yourself,
but you may have more control of execution priorities. Probably it
is less resource intensive.

I think (not sure) heavy-duty server products like Apache will
instance a restricted number of threads, each of which
then asynchonously handles a large number of requests.

"Alan Cabrera" <mag...@spam.users.sf.net> wrote in message
news:b7l99d$t8a$1...@reader1.panix.com...

Alan Cabrera

unread,
Apr 18, 2003, 9:52:51 AM4/18/03
to
How is it that you have more control over execution priorities? How is it
less resource intensive?

My impression of an asynchronous socket is that it's a way that a guy can
get some decent performance without a whole lot of trouble. However, if you
are writing a heavy-duty server, you'll want to manage the threads yourself
and use a synchronous socket. Is my impression correct?

Regards,
Alan

"User" <Us...@aol.com> wrote in message


> It seems to me that with Threading, you can spawn off execution
> threads (each with new instances of required classes) and then
> have the dotnet/os scheduler juggle them.
>
> With asynchronous sockets, you have to do more juggling yourself,
> but you may have more control of execution priorities. Probably it
> is less resource intensive.
>
> I think (not sure) heavy-duty server products like Apache will
> instance a restricted number of threads, each of which
> then asynchonously handles a large number of requests.
>
> "Alan Cabrera" <mag...@spam.users.sf.net> wrote in message
>

Christopher Lord

unread,
Apr 19, 2003, 3:57:41 AM4/19/03
to
Async Socket uses the IO Completion API in the background, which is
extremely efficent when handling large workloads.

Putting a sync. socket inside its own thread is very simple to code and
understand, but it is very inefficent when you go over a certain number of
connections, due to something called context switching. Basically, the
time spent by the OS changing between your threads is greater than the
time actually spent servicing clients. This 'wasted' time adds up very
quickly as you add new threads.

Async Sockets use a very efficent thread pool in combination with the IO
completion port API, so there is much less context switching occuring
behind the scenes.

Async sockets are slightly harder to implement and understand, but once
you are used to this 'style' of network programming, it becomes much
easier.

--
- Christopher Lord
www.clawbox.com

"Alan Cabrera" <mag...@spam.users.sf.net> wrote in

news:b7l99d$t8a$1...@reader1.panix.com:

Alan Cabrera

unread,
Apr 19, 2003, 11:11:54 AM4/19/03
to
A very informative and helpful reply.

Thanks,
Alan

"Christopher Lord" <claw...@nospamplease.hotmail.com> wrote in message
news:Xns936213F62BCC562...@24.70.95.211...

0 new messages