Session Sharing with ReliableSession

Hi,

In the .NET 3.0 SDK documentation is an example of how to share the same session between two clients.

In the example the clients use a custom message header for inserting an id in the message. By sharing this id between the clients, the session can be shared.

I'm currently implementing the exactly same thing, however I'd like to reuse the reliableSession binding that comes with WCF for maintaining sessions.

Now, the problem is, that I can not simply take the custom header from client1 and put it into the message I'm sending with client2 because I don't have a custom header.

Essentially, what I'd like to do is the following:

ChannelFactory<IOutputChannel> cf = new ChannelFactory<IOutputChannel>(binding);
IOutputChannel channel = cf.CreateChannel(replyTo);
// somehow add session information from "client1" to c here so that it will be included in outgoing message!!!
channel.Send(msg);

I've tried to alter the channel directly, but all the session related fields are read-only...

Anybody an idea how this could work

Cheers,
patric

Answer this question

Session Sharing with ReliableSession

Scott McKeown
I think i get it. Let me ask you another question:

If Service A sends message X to Service B and, eventually, Service B sends message Y to Service A - how do you expect to know what instance of Service A should process Y Are you saying you want leverage per session instancing I think that might be a bad idea and we'll have to come up with a different approach for what you are doing.

--Stefan
Dietz
Yes, but it creates a new session.
Mark The Archer Evans
Hi Brian,

No, I haven't implemented a custom channel and YES, I want the second client to 'get on board' with the same session as you have guessed correctly =) Do you know if this is somehow possible In my opinion it should be, because all that really matters is the session stuff in the messages that are sent back and forth, independent of whether I open or close connections or create different client instances etc.

Also, I'm not sure if I'm missing out, but isn't that what the sample illustrates They just do it with a custom application session header, but essentially the service can not distinguish client1 and client2, because they share the same session ids.

Anyway, that doesn't really matter. I think you understood what I was talking about. So any chance you know how this can be done

Cheers,
patric
erikkl2000

I'm still not sure I understand your question.

Are you saying you have implemented a custom channel, and you are trying to do session sharing using that custom channel (without using an application-level message header) If that's the case, you could attach a MessageProperty to the Message at the app level, and have the channel detect the presence of this property and transform it into a header (or whatever 'wire format' you'll eventually use to communicate the session information).

Or do you somehow want the second client to 'get on board' with the same RM session, so that the server-side RM channel thinks that both clients are part of the same RM session (as opposed to the sample, where both client use different RM sessions but the server InstanceContext extensibility yields a shared 'application session')

Is those aren't what you're doing, then can you describe in more detail what's 'the same' and what's 'different' compared to the sample
Anton__

I am confused; the sample you call out already uses RM, right

That is, the sample includes a config that uses this binding:

<bindings>
<wsHttpBinding>
<binding name="BindingWithSession">
<reliableSession enabled="true"/>
</binding>
</wsHttpBinding>
</bindings>
Dan0001
Hi Stefan,

I'm currently implementing an SSDL engine (see http://www.ssdl.org) that extends WCF. In SSDL interactions between services are modeled purely as one-way messages. The SSDL engine I'm writing basically ensures that incoming and outgoing messages are valid according to the defined protocol.

After validating those freely floating one-way messages they are correlated according to the SSDL protocol information (which basically defines, in which order messages can be exchanged). Because an interaction protocol can be composed of many individual one-way messages I need to maintain some kind of conversation state (i.e. session state).

Example:
Service X sends a Message A to Service Y. The middleware of Y validates and dispatches A to a local service method of Y. At the end of the method Service Y decides to send back a Message B to Service X.

Note that all service operations are one-way (i.e. no return value), because messages are not correlated according to operations (i.e. input-output). For example, Service Y could also have send a Message C or a Message D back to Service X, if that was defined in the protocol.

Now, the point why I started this thread was when (in the above example) Service Y sends back a Message B to Service X. Basically my Service Y needs to look at the session id of the (incoming) Message A and put that same information into the outgoing Message B, because these messages belong to the same conversation. Also, it is important so that when Service X receives Message B back from Y, it can do the same thing and continue the conversation with the same session id.

When I'm sending back the message from Y to X, I need to open up a new channel (because the operations are only one-way, hence I have no reply channel). Originally I wanted to do it with Duplex contracts, which is actually exactly what I need to do. Unfortunately there were other issues that didn't make it possible to use Duplex contracts, that's why I just use normal channels and open up a new one for each message in each direction.

So, all I want to do is open up a new outgoing Channel for sending back a message that belongs to the same session as the one that arrived through the incoming one.

Hope this makes sense !

Cheers,
patric
cythe
Why are you trying to share the reliable session It would help if you could describe your scenario; it might be that there is some other wrinkle to the problem.
Session Sharing with ReliableSession

Answer this question