I had posted an inquiry under another thread, but I guess it was not
noticed. A couple Q's for anyone familiar with the new
Named Pipes classes:

Is there an easy way to run asynchronously... to block the thread
until data is received? (Most sample code uses "while (true)" polling
loops which would waste CPU cycles)

Also, is there a convention for which program is the 'server' and
which is the 'client'? The limited sample code that I've seen set up
the transmitting program as the client, but I'm not sure what
difference that makes.

Bob,

There are asynchronous methods on the named pipe classes. They begin
with "Begin" (e.g. "BeginRead", "BeginWrite"), where you will be notified
when they are complete (or you can poll if you wish). The synchronous
methods are simply called Read, Write.

Are you communicating between two .NET programs? If you don't have a
need to support other applications which don't have access to .NET or COM,
then why not use WCF with a named pipe binding? It would be much easier
than having to figure out the messaging pattern on your own, as well as
serialization of types across the channel.


--
- Nicholas Paldino [.NET/C# MVP]
- "Bob" <Bob@nospam.com> wrote in message
news:ukloi459bq3fv59mkldl228qqc0thri0jj@4ax.com...
>I had posted an inquiry under another thread, but I guess it was not
> noticed. A couple Q's for anyone familiar with the new
> Named Pipes classes:
>
> Is there an easy way to run asynchronously... to block the thread
> until data is received? (Most sample code uses "while (true)" polling
> loops which would waste CPU cycles)
>
> Also, is there a convention for which program is the 'server' and
> which is the 'client'? The limited sample code that I've seen set up
> the transmitting program as the client, but I'm not sure what
> difference that makes.
>

Bob wrote:
> Is there an easy way to run asynchronously... to block the thread
> until data is received? (Most sample code uses "while (true)" polling
> loops which would waste CPU cycles)

If you want to block, then why use async - sync would solve the
problem.

Arne

On Tue, 25 Nov 2008 15:03:35 -0500, "Nicholas Paldino [.NET/C# MVP]"
<mvp@spam.guard.caspershouse.com> wrote:

>Bob,
>
> There are asynchronous methods on the named pipe classes. They begin
>with "Begin" (e.g. "BeginRead", "BeginWrite"), where you will be notified
>when they are complete (or you can poll if you wish). The synchronous
>methods are simply called Read, Write.

I was trying to avoid polling, mostly to keep from wasting cycles.
It's been quite a while since I've looked at Named Pipes, and of
course that was in unmanaged C++. I'll keep looking for sample code
for the .NET calls. Should be somewhere now that Named Pipes are
officially supported.

> Are you communicating between two .NET programs? If you don't have a
>need to support other applications which don't have access to .NET or COM,
>then why not use WCF with a named pipe binding? It would be much easier
>than having to figure out the messaging pattern on your own, as well as
>serialization of types across the channel.

Yes, I'll eventually be checking into WCF. For now, one app is .NET,
the other is Win32 unmanaged. Not sure if WCF could still be used in
any form on the .NET side.

On Tue, 25 Nov 2008 21:53:18 -0500, Arne Vajhøj <arne@vajhoej.dk>
wrote:

>Bob wrote:
>> Is there an easy way to run asynchronously... to block the thread
>> until data is received? (Most sample code uses "while (true)" polling
>> loops which would waste CPU cycles)
>
>If you want to block, then why use async - sync would solve the
>problem.
>
>Arne

Got sidetracked with a couple other things, but just got back to this.
While the straight asynch WaitForConnection()/Read() functions would
block, as I wanted, there does not seem to be any graceful mechanism
for interacting after the asynch calls are made. They would be a
temporary dead end until the next state change.

So if the thread needs to be closed (app shutdown or whatever), it
seems inelegant to just end the thread. And recovery from errors
(client disconnects, for example) does not seem easy.

The goal is simply to have the server wait for client apps to connect,
but I'd like to continually monitor status, and afford the opportunity
to recover from errors, etc. Seems like there should be available
samples that show how to code the framework, but I haven't found
anything yet.