When you create a sessionful channel, that implies the existence of some correlation factor for all of the messages that are associated with the session. For example, the correlation factor for a TCP session is that all of the messages travel over the same TCP connection and the correlation factor for a WS-RM session is that all of the messages belong to the same reliable sequence. There is no way to identify what the correlation factor is at runtime but the channel provides an ISession object so that one correlation factor is distinguishable from another. This is done just by having a unique identifier associated with the session. Since the session and session identifier are part of the channel interface for a sessionful channel, it's possible to try to access the session as soon as the channel is created. However, there's no guarantee that the session information is valid if the channel is not open at the time. Here is how some of the standard client-side sessions behave if accessed after the channel is created but before the channel is opened. TCP session: A unique identifier is generated on the fly, this identifier will continue to be used after the channel is opened. Reliable session: The session identifier is empty, an identifier will be created when the channel is opened. Security session: Trying to access the identifier produces a runtime exception, an identifier will be created when the channel is opened. In short, you can't rely on any meaningful behavior for the session until you're ready to start sending data. Next time: Substituting for TryAccept
Read More...