Re: server scenario - variables in the right spot?

thanks Peter. I figured I wasn't using the async model correctly. I'm having
a hard time visualizing how the client-server conversation looks (in code)
when done as you suggest (without waithandles). Inevitably there is a
conversation in which one side can't take the next step until an answer is
received. So how is this 'wait' handled using asynch api as its supposed to
be used? I can grasp the beginAccept callback posting another beginAccept as
opposed to the loop structure I have in my example (in fact I think I'll
make that change), but as you put it, the 'connection-specific stuff with
sending and receiving', thats where I can't visualize the asynch structure,
other than how I did it (using waithandles)... it seems my head needs that
'control' or 'main' thread to keep things straight. For example, in some
cases my beginReceive callback posts another beginReceive until all data is
received, but its another thread that started that receive operation in the
first place and is waiting to do something with what is received... You
*are* suggesting I would not need that 'control' or 'main' thread approach
if using asych api better, right? what would that look like? no waithandles?
makes my brain twist in ways its not meant to.. hehe. :)

"Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx> wrote in message
news:op.ttkhez158jd0ej@xxxxxxxxxxxxxxxxxxxxxxx
On Thu, 07 Jun 2007 12:21:21 -0700, David <nospam@xxxxxxxxxx> wrote:

i think i just realized i'm an idiot. again.

For what it's worth, I've seen idiots around here, and you ain't it. :)

thanks.


[...] What happens when many
clients are being serviced at the same time? Will they all be using those
SAME AutoResetEvents and screwing each other up?
[...]

Well, the biggest issue I see is that you should not need the events at
all. Instead, for example, your AcceptCallback() method should post
another Socket.BeginAccept(). Likewise sending and receiving.

You are correct that there is some potential for interference between
clients (though actually, the accept case is probably okay...it's the
connection-specific stuff with sending and receiving where things get
messy), but that all is avoided if you take advantage of the inherent
threading model that the asynch API provides in the first place.

Pete


.

Relevant Pages

  • Re: partially received or failed fax
    ... I recently installed the SBS 2003 fax server feature with a brand new ... USR 325610B (56K Performance Pro Modem). ... I have a couple of clients ... Receiving is a little more tricky. ...
    (microsoft.public.windows.server.sbs)
  • Re: Eudora question - "extra" file w/sent attachment
    ... machine will only have use for the data fork, and most Windows clients ... The best fix would be for the receiving mail client to get smart about ... AppleDouble encoding is common to all Mac mail clients and is a ...
    (comp.mail.eudora.mac)
  • Re: mass mailing problem
    ... "EvilNem" wrote: ... receiving the attachment...they can get the attachment when the email is ... clients, one email is jo@xxxxxxxxxxxxxxxxxxx that doesn't get the ... get any computer virus from a pdf file. ...
    (microsoft.public.exchange.admin)
  • Re: mass mailing problem
    ... "EvilNem" wrote: ... receiving the attachment...they can get the attachment when the email ... clients, one email is jo@xxxxxxxxxxxxxxxxxxx that doesn't get ... get any computer virus from a pdf file. ...
    (microsoft.public.exchange.admin)
  • Re: mass mailing problem
    ... "EvilNem" wrote: ... receiving the attachment...they can get the attachment when the email is ... clients, one email is jo@xxxxxxxxxxxxxxxxxxx that doesn't get the ... get any computer virus from a pdf file. ...
    (microsoft.public.exchange.admin)