Listener won't accept new channel after first one is finished

Hey,

I posted regarding my custom transport, and the including of security the other day. I solved that problem but it seems like the adding of security caused some more trouble.

This is on the server side, where a ServiceHost is used.
Without security this was what usually happened (using reliable messaging though):

  1. In the Listener, OnBeginAcceptChannel() is called, and an async setup of communication is done. When ready OnEndAccept() is called, and a ReplyChannel is returned.

  2. On this channel ReceiveRequest() is called and a RequestContext is returned.

  3. Using the RequestContext.Reply() a reply is sent.
  4. Back to (1), where a new channel is created for the next message...


Now, with security, BeginReceiveRequest is called in (2) instead of the sync version used before.

And now to the problem.

For some reason (4) is never reached while using security. Instead ReceiveRequest (2) keeps being called. I figure this might be because the same channel is supposed to handle the whole secure session, instead of a new channel being created for each message?

But, even after the whole secure (and RM) session is over, the BeginReceiveRequest (2) keeps being called, and the channel never dies. Which means the Listener never creates a new channel.

I'm thinking I might be missing some call to a Close() or Dispose() method or something, somewhere? But why would I have to explicitly call something like that now with security, but not before?

Might there be something special I should do in RequestContext.Close() or dispose? In there I only call Message.Close() right now.

So, basically, I was hoping someone would know how to make the channel die, and get the Listener to start accepting a new channel.

Thanks,
Pat

[1991 byte] By [PatrikJ] at [2007-12-23]
# 1

The way to signal that no more messages are coming in over your channel is to return null from [Begin]ReceiveRequest. My question for you is, why do you need to create a new IReplyChannel for each message? If you are not session-ful, then the best practice is to reuse the same channel until it's closed...

KennyWolf at 2007-8-30 > top of Msdn Tech,Visual Studio Orcas,Windows Communication Foundation (Indigo)...
# 2

Well, I don't really need one for each message, but one for each session at least. Which I wasn't getting.

Anyway, it still doesn't really work. If I return a null from BeginReceiveRequest i get a NullReferenceException (it expects an IAsyncResult).

If I return a null from EndReceiveRequest, the channel seems to die, but still no new one is started.

Any ideas why?


Thanks,
Pat

PatrikJ at 2007-8-30 > top of Msdn Tech,Visual Studio Orcas,Windows Communication Foundation (Indigo)...
# 3
Since you are IReplyChannel, the infrastructure is assuming that when you return null there are no more messages ever coming in. That's because IReplyChannel is not sessionful. It's a datagram channel. Think of it like a UDP socket. If you want to expose sessionful channels then you should create IReplySessionChannel. Then the runtime will create new channels when you signal End of Session by returning null.
KennyWolf at 2007-8-30 > top of Msdn Tech,Visual Studio Orcas,Windows Communication Foundation (Indigo)...

Visual Studio Orcas

Site Classified