Prev: Dynamically creating an ActiveX on a WPF/Windows .Net app
Next: DataContractJsonSerializer Serializes item, then cannot deserializ
From: PFx on 9 Oct 2008 04:35
Hi, i am having a difficult time with developing an application using
asynchronous named pipes. I use a NamedPipeServerStream but for some reason
my beginwaitforconnection-callback-method gets executed at 'strange' times;
like when closing the server. The server-application is a Windows-forms app

Do I have to disconnect in the callback-method?
Am I missing something else?


The namedpipeserverstream is set up in method main()

internal void main()
{

this._pipe = new NamedPipeServerStream("abc"
, PipeDirection.In
, 1
, PipeTransmissionMode.Byte
, PipeOptions.Asynchronous
);

setUpPipe();

Application.Run(new Form1());
}

My callback-code looks like this:

private void setUpPipe()
{

this._pipe.BeginWaitForConnection(
iar => {

this._pipe.EndWaitForConnection(iar);

System.Diagnostics.Debug.WriteLine("...");

this._pipe.Disconnect();

setUpPipe();

}
, null
);
}


Kind regards
From: Peter Duniho on 9 Oct 2008 13:39
On Thu, 09 Oct 2008 01:35:01 -0700, PFx <PFx(a)discussions.microsoft.com>
wrote:

> Hi, i am having a difficult time with developing an application using
> asynchronous named pipes. I use a NamedPipeServerStream but for some
> reason
> my beginwaitforconnection-callback-method gets executed at 'strange'
> times;
> like when closing the server. The server-application is a Windows-forms
> app
>
> Do I have to disconnect in the callback-method?
> Am I missing something else?

It's hard to say without a concise-but-complete code sample to illustrate
exactly what you're doing.

However, it's true that if you close your pipe, the operation you started
will complete, with an error. My guess is that if in your callback
method, you checked for an error (e.g. with a try/catch block) you'd see
that's what's going on. And yes, it's perfectly normal and expected.

Pete
From: PFx on 10 Oct 2008 04:12
Thanks for your advice.
It 's exactly what I ended with.

But I am still confused with the 'maxNumberOfServerInstances'-parameter
in the constructor. If > 1, how does it map to threads? I still have to
create some more background-threads and an equal number of pipe-instances for
my multithreaded-listener-application (?).
Documentation and community-info about this topic is quite sparse ...

private void setUpPipe()
{
this._pipe.BeginWaitForConnection(
iar => {
try
{
this._pipe.EndWaitForConnection(iar);

if (!this._pipe.IsConnected) { return; }


Trace.WriteLine("Do something");

this._pipe.Disconnect();

// Continue listening.
setUpPipe();
}
catch (ObjectDisposedException) {} // Application shutdown.
catch (Exception exx)
{
Trace.WriteLine("2: " + exx.ToString());
}
}
, null
);
}


Thanks and regards

Philippe



"Peter Duniho" wrote:

> On Thu, 09 Oct 2008 01:35:01 -0700, PFx <PFx(a)discussions.microsoft.com>
> wrote:
>
> > Hi, i am having a difficult time with developing an application using
> > asynchronous named pipes. I use a NamedPipeServerStream but for some
> > reason
> > my beginwaitforconnection-callback-method gets executed at 'strange'
> > times;
> > like when closing the server. The server-application is a Windows-forms
> > app
> >
> > Do I have to disconnect in the callback-method?
> > Am I missing something else?
>
> It's hard to say without a concise-but-complete code sample to illustrate
> exactly what you're doing.
>
> However, it's true that if you close your pipe, the operation you started
> will complete, with an error. My guess is that if in your callback
> method, you checked for an error (e.g. with a try/catch block) you'd see
> that's what's going on. And yes, it's perfectly normal and expected.
>
> Pete
>
From: Peter Duniho on 10 Oct 2008 07:13
On Fri, 10 Oct 2008 01:12:01 -0700, PFx <PFx(a)discussions.microsoft.com>
wrote:

> Thanks for your advice.
> It 's exactly what I ended with.
>
> But I am still confused with the 'maxNumberOfServerInstances'-parameter
> in the constructor. If > 1, how does it map to threads? I still have to
> create some more background-threads and an equal number of
> pipe-instances for
> my multithreaded-listener-application (?).
> Documentation and community-info about this topic is quite sparse ...

Unfortunately, named pipes support is brand-new in .NET, and so it's
likely information on the specifics will be sparse for the near future.

I myself have very little knowledge of it. I would say that for the most
part, you should not concern yourself too much with the specifics and
worry more about how the observable behavior affects you. That is, if you
need multiple servers to be available on the same named pipe, then go
ahead and do that, and trust .NET to implement it in a reasonably
efficient way.

Whether .NET does or not, I can't say. But if you code to the API, then
if and when the API is improved (assuming it needs to be), your own code
will simply wind up taking advantage of that without additional effort on
your part.

I don't actually recall whether in the unmanaged named pipes API, i/o
completion ports are supported. Because they act in a fashion very
similar to file i/o, and because IOCP is supported for file i/o, I
_believe_ that IOCP is supported for named pipes as well. And given that
IOCP is used in other areas of .NET, it stands to reason that the .NET
implementation of named pipes would also use IOCP.

If all of that is true, then multiple servers would not actually map
one-to-one to extra threads. Rather, the IOCP thread pool would be used,
taking advantage of the efficiency gains IOCP offers.

If it's really important for you to know the exact details, you may have
to simply observe the behavior in the debugger, or look at the .NET source
code (either via Reflector or Microsoft's own source download service),
and see how it works.

Pete
 | 
Pages: 1
Prev: Dynamically creating an ActiveX on a WPF/Windows .Net app
Next: DataContractJsonSerializer Serializes item, then cannot deserializ