When writing an IDuplexSessionChannel
, one of the pieces that needs to be implemented is (as you might expect) IDuplexSession
. IDuplexSession
has one additional requirement on top of ISession, and that is the ability to perform a “half-close”. Semantically this is the same as Shutdown(Send) in sockets-speak.
When you call IDuplexSession
.CloseOutputSession()
, this signals to the other side of the session that it should return null from outstanding and subsequent calls to Receive()
. CloseOutputSession() is also idempotent (just like ICommunicationObject
.Close()
and ICommunicationObject
.Abort()
).
CloseOutputSession() is also a little tricky, because it’s a session method that can interact with the owning IDuplexSessionChannel
that owns the session. In particular, if your session lifetime is coupled with your channel lifetime (like it is for TCP and RM and Security):
- If CloseOutputSession() is called before channel.Close(), channel.Close() should wait for CloseOutputSession() to finish.
- If the channel is in the Created or Opening state, CloseOutputSession() should
throw new
InvalidOperationException(...)
. - If the channel is in the Faulted state, CloseOutputSession() should
throw new
CommunicationObjectFaultedException(...)
. - The channel should fault if CloseOutputSession throws.
- channel.Close() should call CloseOutputSession() and then verify that Receive() returns
null
(i.e. CloseOutputSession was called from the other side of the session).
Hi Kenny, hey it looks like MaxMessageSize is gone in RC0/FebCTP…I’m guessing that’s because the setting is the same for both maxmessagesize and maxbuffersize regardless. Is that right?
No, the two concepts still exist but MaxMessageSize has been renamed MaxReceivedMessageSize as it only applies to the received message. Perhaps we should have renamed MaxBufferSize to MaxReceivedBufferSize as well….
Pingback: kennyw.com » Blog Archive » Signalling “End Of Session”