Both the Session and the SecureChannel layers have timeout mechanisms defined to free up resources if the client is inactive for a time.
But I can’t find any information in Part 6 what to do with the TCP connection when a SecureChannel is timed out. If the client is inactive and the SecureChannel has timed out it will probably not close the TCP connection either. The only information I can find about closing the TCP connection is in Part 6, chapter 7.1.4, which says the client shall close the TCP connection when it has closed the SecureChannel.
In chapter 7.1.3 I also found this sentences: “Servers shall close any socket after a period
of time if it does not receive a Hello Message. This period of time shall be configurable and
have a default value which does not exceed two minutes”.
But this only states what to do with a TCP connection which haven’t received a Hello message. What to do with a TCP connection which has been abandoned by the client (i.e. the SecureChannel has timed out)?
Shall the TCP connection be closed once the SecureChannel times out? Or shall it be possible for a new client to take over a TCP connection that does not have a SecureChannel?
Moderators-Companion
02/24/2014
Hello,
There is clearly a dependency between Session, SecureChannel and TCP socket. You are right that the released specifications do only talk about timeouts at each level and not about dependency. But some of the independence is intentional.
But we will add clarifications in the next release 1.04 specification. This clarification explains that resources can be freed if the server needs new resources but runs out of resources and an old resource is not longer used by high levels. E.g. an old SecureChannel can be deleted if no Session is connected and resources for a new SecureChannel is needed.
From Part 4 – 5.5.2 OpenSecureChannel (upcoming version 1.04)
To protect against misbehaving Clients and denial of service attacks, the Server shall close the oldest SecureChannel that has no Session assigned before reaching the maximum number of supported SecureChannels.
A TCP socket is always bound to a SecureChannel. If the SecureChannel is closed, the socket is closed too.
If a TCP socket is opened but not used after a period of time, it is also closed.
From Part 6 – 7.1.3 Establishing a connection (upcoming version 1.04)
Applications accepting incoming connections shall close any TransportConnection after a period of time if it does not receive a Hello or ReverseHello Message. This period of time shall be configurable and have a default value which does not exceed two minutes.
Matthias
Thanks for a good response!
Will there be any clarifications added to Part 6? I think part 6 is clear in that if the client closes the secure channel it shall also close the TCP connection. Also if no Hello message is received the TCP connection shall be closed after a configured period of time. But the following cases are not clear to me:
- If the Client sends the Hello message but does not open a SecureChannel.
- If the Client closes the SecureChannel but does not close the TCP connection.
- If the SecureChannel times out.
A TCP socket is always bound to a SecureChannel. If the SecureChannel is closed, the socket is closed too.
Do you mean that the server always shall close the TCP connection if the SecureChannel is closed? If a server always closes the TCP connection when the SecureChannel is closed (by the client or by timeout) would violate the current Part 6 specification if the client is closing the SecureChannel but solve issues with limited resources if the channel times out.
As you explain in your response another solution would be to handle TCP connection similar to how SecureChannels are handled. I.e. let the TCP connection remain active if a client doesn’t close the TCP connection after the SecureChannel has been closed or if the SecureChannel times out. But if a TCP connection resource is needed first look for unused connection (not attached to a SecureChannel) and use it before taking from the free resources.
What solution should I implement?
1 Guest(s)