rippled/init.txt

server
   -> endpoint
         -> transport




server
- parent of endpoint, so inheirits all of endpoint


endpoint
- can create connections
- knows types
-- endpoint
-- connection
-- endpoint transport
-- connection transport


endpoint transport
- knows types
-- endpoint transport
-- connection transport

- has endpoint specific transport state
-- acceptor
-- io_service


connection
- knows connection type

connection transport
- has connection specific transport state
-- socket


#######################
# Initialization Loop #
#######################

Endpoint Construction Phase (every step here happens in reverse)
- role constructor
- endpoint constructor
-- sets useragent and is_server
- transport endpoint constructor
-- ASIO: set external_io_service false
-- ASIO: state: uninitialized
- socket endpoint constructor

Endpoint Initialization Phase
- set handlers (optional)
- set on_tls_init (required for use of transport::asio::tls_socket::endpoint)
- Server needs no initialization?
- Endpoint needs no initialization?
- ASIO: call to transport::endpoint::init_asio
-- creates (or sets) the io_service
-- sets external_io_service
-- initializes acceptor
-- sets state to ready
- IOSTREAM: register_ostream
- SERVER ASIO: listen(...)
-- sets state to listening
-- opens acceptor
-- sets some acceptor options
-- binds the acceptor
-- starts listening
- SERVER ASIO: start_accept
-- will create a new connection
-- will queue up async_accept on that connection's socket
-- when the socket is accepted or an error occurs, the connection will either be
   started or terminated. Afterwards a new accept operation is initiated.
- SERVER ASIO: start io_service
-- If using the internal io_service this typically means run()
-- If using an external io_service you are free to run it however you like or
   perform the above steps using an already running io_service.


Connection Initialization Phase

###############


create a server
call any transport init required by the transport you are using
call server->start_accept();



start_accept
- Create a new connection
- Ask transport




#############################
# Endpoint API (Thread Safe #
#############################


##################
# Connection API #
##################
send message





########### Other development notes previously from websocketpp.hpp ############
/*

Endpoint
- container for connections
- Store and forward default connection settings

Connection
- Represents the state and functionality of a single WebSocket session starting 
  with the opening handshake and completing with the closing one.
- After a connection is created settings may be applied that will be used for
  this connection. 
- Once setup is complete a start method is run and the connection enters its 
  event loop. The connection requests bytes from its transport, then runs those
  bytes through the appropriate websocket frame processor, and calls handler
  methods appropriate for the types of frames recieved.





Policies:

Concurrency






Concurrency Models
Single Thread Async (lock free)
- WS++ runs lock free (Access to endpoint and connection from non-WS++ threads is unsafe)
- All handlers and networking operations run in a single thread.
- Handlers can block each other and network operations
- Good for low traffic workflows where connections are independent and requests are short.

Single Thread Async
- Same as lock free version except access to endpoint and connection from non-WS++ threads is safe
- Good for workflows where any long running handler job is deferred to a non-WS++ thread for processing.

Thread Pool (lock free)
- WS++ runs lock free (access to endpoint and connection from non-WS++ threads is unsafe)
- Handlers and networking operations invoked by multiple threads. Individual connections are serialized.
- n handlers will block network operations (n=num_threads)
- Allows much better multi-core utilization, does not require end user syncronization as long as all work is performed inside handlers and handlers only reference their own connection. Handler local data must be syncronized.

Thread pool
- Same as lock free version except access to endpoint and connection from non-WS++ threads is safe.

Thread per connection
- 

io_service policies
- external vs internal
- per endpoint or per connection


message policies?
- Control Messages:
-- Each connection should have a single control message permanently allocated
- Data Messages
-- Dynamically allocate a new data message as needed.
-- Re-usable pool of data messages per endpoint
-- Re-usable pool of data messages per connection


*/