LateNightHacking Louis Journal

Auth

Ideas about Sessions:

• Split into high and low session. High is protocol oriented, low is socket oriented.
• A low session should be compatible with just about any protocol. It defines a persistent socket connection.
• An end point should be enhanced to be an event generating object.
• A low session also provides threading guarantees.
• Should make it so completion of all requests can be detected - no ambiguity if not necessary
• Should be able to run multiples high sessions. There may be a session control protocol or mid session. (is there a difference between high and mid sessions?)
• Must provide back pressure.
• Can take advantage of an extended thread framework, such as thread roles. A thread role defines a scheduling context with particular constraints. Primary purpose is to simulate multiple dedicated threads when those threads are not often called upon.
• Need to define what is and is not provided at each session level. A low session is a connection, a mid session defines a protocol and things like failover and high session muxing, a high session defines an interface. A high session may integrate multiple low sessions. many high sessions may share one low session. a high session may failover between multiple low sessions. An endpoint may be altered for a low session (a DNS name becomes resolvable, or a server is moved to another box).
• A (low) session means that client code does not have to deal with the two cases of a connection existing and a connection not existing. A session exists to make error handling uniform. For example you can't send a message if you haven't created a connection object yet. However, you can always send a message to a session even if it hasn't established a connection. The error path is the same whether the server rejected the message, the connection just died, or the connection had not yet come into existence.
• The complex state for managing a robust connection can be hidden from client code. Either the connection is working or it is not. However, the client is always aware that the request is potentially expensive, and is always kept aware of the connection status (though it may choose to ignore these events).
• A low session has two major states: connected, and disconnected. Connected has two minor states: connecting and connected. Disconnected has two minor states: stopped, and pessimisticly connecting. Notice that the connected-connecting state can be treated like the connected-connected state with maximum back-pressure (a full send buffer).
• a mid session is probably not accessible directly from client code. It's state transitions do not overtly affect clients. Presumably it will negotiate once a connection is established.
• high sessions mave new states when managing subscriptions: disconnected, connected - waiting for initial data, connected - waiting for update complete, and connected - up to date. (Can connected - (waiting for initial data) be deleted? is it required to detect the error condition of update before refresh?)