ARCHIVE/rippled
1
0
Fork 0
mirror of https://github.com/XRPLF/rippled.git synced 2026-04-29 15:37:57 +00:00
Code Issues Packages Projects Releases Wiki Activity

updates non-code supporting documentation

Browse Source
This commit is contained in:
Peter Thorson
2013-05-09 07:11:59 -05:00
parent d85ea32851
commit 273c8e82b0
5 changed files with 72 additions and 193 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
COPYING Normal file
View File

@@ -0,0 +1,23 @@
Copyright (c) 2013, Peter Thorson. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
* Neither the name of the WebSocket++ Project nor the
names of its contributors may be used to endorse or promote products
derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL PETER THORSON BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

2
changelog.md Normal file
View File

@@ -0,0 +1,2 @@
0.3.0b1 - 2013-05-??
- Initial Release

179
init.txt
View File

@@ -1,179 +0,0 @@
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
*/

47
readme.md Normal file
View File

@@ -0,0 +1,47 @@
WebSocket++ (0.3.x branch)
==========================
WebSocket++ is a header only C++ library that impliments RFC6455 The WebSocket
Protocol. It allows C++ programs to impliment WebSocket client and server
functionality. It uses interchangable network transport modules including one
based on C++ iostreams and one based on Boost Asio.
*This branch is no longer "experimental". It represents the current edge release
of the WebSocket++ library. The API of 0.3.x has some significant changes from
0.2.x, so care should be taken when upgrading.
This branch's API is relatively stable now. Features implimented so far are
unlikely to change (except where explicitly noted). New features will be added
regularly until parity with the 0.2 branch is reached.
This is the preferred branch for new projects, especially those that involve
multithreaded servers. It is better tested and documented. The 0.3.x API will
be the basis for the 1.0 release.*
Major Features
==============
* Full support for RFC6455
* Partial support for Hixie 76 / Hybi 00, 07-17 draft specs (server only)
* Message/event based interface
* Supports secure WebSockets (TLS), IPv6, and explicit proxies.
* Flexible dependency management (C++11 Standard Library or Boost)
* Portible, cross platform and architecture design
Get Involved
============
**Project Website**
http://www.zaphoyd.com/websocketpp/
**GitHub Repository**
https://github.com/zaphoyd/websocketpp/
**Announcements Mailing List**
http://groups.google.com/group/websocketpp-announcements/
**Discussion / Development / Support Mailing List / Forum**
http://groups.google.com/group/websocketpp/
Author
======
Peter Thorson - websocket@zaphoyd.com

14
readme.txt → roadmap.md
View File

@@ -1,17 +1,3 @@
WebSocket++ 0.3.x branch
This branch is no longer "experimental". It represents the current edge release
of the WebSocket++ library. The API of 0.3.x has some significant changes from
0.2.x, so care should be taken when upgrading.
This branch's API is relatively stable now. Features implimented so far are
unlikely to change (except where explicitly noted). New features will be added
regularly until parity with the 0.2 branch is reached.
This is the preferred branch for new projects, especially those that involve
multithreaded servers. It is better tested and documented. The 0.3.x API will
be the basis for the 1.0 release.
Complete & Tested:
- Server and client roles pass all Autobahn v0.5.9 test suite tests strictly
- Streaming UTF8 validation