admin/snoop_device
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

first commit

Browse Source
This commit is contained in:
sanya
2025-09-01 14:20:39 +00:00
committed by ExternPointer
commit 490fc11f6a
4328 changed files with 1796224 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

138
third_party/socket.io-client-cpp/lib/websocketpp/docs/config.dox vendored Normal file
View File

@@ -0,0 +1,138 @@
/** \page reference.config Config Reference
WebSocket++ uses a config template parameter to supply a number of compile type policy types and default numerical values for buffer sizes, timeouts, security behavior, etc. Swapping policies allows changing certain core library behavior designed to be pluggable.
A custom config can be made standalone or can subclass one of the bundled configs and just override a few things.
__Example__
```
// some config options may require additional includes or dependencies.
// syslog logging policy, for example, requires <syslog.h>,
// the permessage deflate settings require zlib.
#include <websocketpp/logger/syslog.hpp>
#include <websocketpp/extensions/permessage_deflate/enabled.hpp>
// Custom server config based on bundled asio config
struct custom_server_config : public websocketpp::config::asio {
// Replace default stream logger with a syslog logger
typedef websocketpp::log::syslog<concurrency_type, websocketpp::log::elevel> elog_type;
typedef websocketpp::log::syslog<concurrency_type, websocketpp::log::alevel> alog_type;
// Reduce read buffer size to optimize for small messages
static const size_t connection_read_buffer_size = 1024;
// enable permessage_compress extension
struct permessage_deflate_config {};
typedef websocketpp::extensions::permessage_deflate::enabled
<permessage_deflate_config> permessage_deflate_type;
};
typedef websocketpp::server<custom_server_config> server_endpoint_type;
```
Core Config Options
-------------------
### Policies
Policies are classes used to allow clean swapping of behavior without changing the core library
| Typedef Name | Effect |
| ------------------------- | -------------------------------------- |
| concurrency_type | Concurrency policy |
| elog_type | Error logger type |
| alog_type | Access logger type |
| request_type | HTTP request type |
| response_type | HTTP response type |
| message_type | Type to deliver recieved messages |
| con_msg_manager_type | Connection level message manager |
| endpoint_msg_manager_type | Endpoint level message manager |
| rng_type | Random Number Generation policy |
| transport_type | Transport policy to use |
| endpoint_base | User overridable Endpoint base class |
| connection_base | User overridable Connection base class |
### Timeouts Values
These represent the length of time (in ms) before the given operation is aborted
| Field | Type | Default | Operation |
| ----------------------- | ---- | ------- | --------------------------- |
| timeout_open_handshake | long | 5000 | Opening handshake |
| timeout_close_handshake | long | 5000 | Closing handshake |
| timeout_pong | long | 5000 | No pong recieved after ping |
### Performance tuning
| Field | Type | Default | Meaning |
| --------------------------- | ------ | -------- | ------------------------------------------------------------------ |
| connection_read_buffer_size | size_t | 16384 | Size of the per-connection read buffer |
| enable_multithreading | bool | true | Disabling may reduce locking overhead for single threaded programs |
#### Connection Read Buffer
Each connection has an internal buffer of this size. A larger value will result in fewer trips through the library and less CPU overhead at the expense of increased memory usage per connection.
If your application primarily deals in very large messages you may want to try setting this value higher.
If your application has a lot of connections or primarily deals in small messages you may want to try setting this smaller.
### Security settings
| Field | Type | Default | Effect |
| ---------------------- | ------ | ------- | -------------------------------------- |
| drop_on_protocol_error | bool | false | Omit close handshake on protocol error |
| silent_close | bool | false | Don't return close codes or reasons |
| max_message_size | size_t | 32MB | WebSocket max message size limit |
| max_http_body_size | size_t | 32MB | HTTP Parser's max body size limit |
#### Drop on protocol error
Drop connections on protocol error rather than sending a close frame. Off by default. This may result in legitimate messages near the error being dropped as well. It may free up resources otherwise spent dealing with misbehaving clients.
#### Silent Close
Silence close suppresses the return of detailed connection close information during the closing handshake. This information is useful for debugging and presenting useful errors to end users but may be undesirable for security reasons in some production environments. Close reasons could be used by an attacker to confirm that the endpoint is out of resources or be used to identify the WebSocket implementation in use.
Note: this will suppress *all* close codes, including those explicitly sent by local applications.
#### Max message size
Default value for the processor's maximum message size. Maximum message size determines the point at which the library will drop a connection with the message_too_big protocol error.
#### Max HTTP header size
Maximum body size determines the point at which the library will abort reading an HTTP message body and return the 413/request entity too large error.
Transport Config Options
------------------------
### Policies
Policies are classes used to allow clean swapping of behavior without changing the core library
| Typedef Name | Effect |
| ---------------- | ------------------ |
| concurrency_type | Concurrency Policy |
| elog_type | Error logger type |
| alog_type | Access logger type |
| request_type | HTTP request type |
| response_type | HTTP response type |
### Timeouts Values
These represent the length of time (in ms) before the given operation is aborted
| Field | Type | Default | Operation |
| ------------------------ | ---- | ------- | --------------------------------------------- |
| timeout_socket_pre_init | long | 5000 | Transport dependent |
| timeout_proxy | long | 5000 | Proxy handshake |
| timeout_socket_post_init | long | 5000 | Transport dependent (commonly: TLS handshake) |
| timeout_dns_resolve | long | 5000 | DNS resolution |
| timeout_connect | long | 5000 | TCP Connect |
| timeout_socket_shutdown | long | 5000 | Socket shutdown |
### Performance tuning
| Field | Type | Default | Meaning |
| --------------------------- | ------ | -------- | ------------------------------------------------------------------ |
| enable_multithreading | bool | true | Disabling may reduce locking overhead for single threaded programs |
*/

162
third_party/socket.io-client-cpp/lib/websocketpp/docs/faq.dox vendored Normal file
View File

@@ -0,0 +1,162 @@
/** \page faq FAQ
## General Library Usage
### Can a handler be changed after a connection is established? Can one be removed?
Yes, but not globally.
Handlers assigned to endpoints will be automatically copied to the connections created by that endpoint. Changing a handler on an endpoint will only affect future connections.
Once a particular connection is created, it's handlers can be changed individually by calling the `set_*_handler` methods. Once changed, all future events of that type for that connection will use the new handler.
To remove a handler that was previously set, call the set method with `nullptr` or `NULL`.
### Can I reject or conditionally accept a connection
Yes. The `validate` handler is called after the initial handshake has been recieved but before WebSocket++ has responded. This gives you the opportunity to inspect the incoming connection request, its headers, origin, subprotocols, and the remote endpoint IP. Return `true` from the validate handler to accept the connection and `false` to reject it.
To set a custom HTTP error message for your rejection, use `websocketpp::connection::set_status` and (optionally) `websocketpp::connection::set_body()` to set the HTTP status code and error message body text. If you do not set body text a message will be generated automatically based on the status code.
### How do I negotiate subprotocols?
WebSocket connections may offer a particular subprotocol they want to use. The WebSocket protocol does not define the meaning or interpretation of the subprotocol. This interpretation is left up to the individual application endpoints.
WebSocket++ servers can read the requested subprotocols during the `validate` handler by calling `websocketpp::connection::get_requested_subprotocols`. The list is ordered by client priority. You may optionally choose one of these subprotocols with `websocketpp::connection::select_subprotocol`. The handshake will then complete and let the client know which one was chosen. If you do not choose any, the "blank"/empty/none subprotocol will be used.
WebSocket++ clients can add a subprotocol to an outgoing connection by calling `websocketpp::connection::add_subprotocol` before calling `websocketpp::client::connect`. The order of adding will be interpreted as the order of preference.
In both caases, after the connection has been established, the selected subprotocol is available via the `websocketpp::connection::get_subprotocol` method.
Note: some browsers will allow the connection to continue if they requested a subprotocol and your server doesn't select one. Others will reject the connection.
### How do I cleanly exit an Asio transport based program
The Asio transport based clients and servers use the Asio library's underlying `io_service` to handle asyncronous networking operations. The standard behavior of the io_service is to run until there are no async operations left and then return. WebSocket++, when using the Asio transport, behaves like a standard Asio application. If you want your WebSocket++/Asio based program to stop network operations and cleanly close all sockets you will want to do the following:
- For servers, call `websocketpp::transport::asio::endpoint::stop_listening` to initiate the closing of the server listening socket.
- For clients, if you have engaged perpetual mode with `websocketpp::transport::asio::endpoint::start_perpetual`, disable it with `websocketpp::transport::asio::endpoint::stop_perpetual`.
- For both, run `websocketpp::endpoint::close` or `websocketpp::connection::close` on all currently outstanding connections. This will initiate the WebSocket closing handshake for these connections
- Wait. Asio is asyncronous. When the calls to the above methods (stop_listening, close, etc) complete the server *will still be listening*, the connections *will still be active* until the io_service gets around to asyncronously processing the socket and WebSocket protocol closing handshakes. The `io_service::run` method will exit cleanly and automatically when all operations are complete.
__WARNING__: Asio's `io_service` has a method called `stop`. WebSocket++ wraps this method as `websocketpp::transport::asio::endpoint::stop`. While this operation has a benign sounding name, it is a powerful and destructive operation that should only be used in special cases. If you are using `io_service::stop` or `endpoint::stop` without a very good reason your program is likely broken and may exhibit erratic behavior. Specifically, `io_service::stop` stops the processing of events entirely. This does not give current operations (such as socket closing handshakes) the opportunity to finish. It will leave your sockets in a dangling state that may invoke operating system level timeouts or other errors.
__Special cases__:
- If your client uses the `start_perpetual` method it will prevent the io_service from exiting even if it has nothing to do. This is useful if you want a client endpoint to idle in the background to allow new connections to be formed on demand rather than generating a new endpoint for each.
- If you are using an external io_service and/or are placing non-WebSocket++ operations on the `io_service` those operations may keep the `io_service` open even after all WebSocket++ operations have completed.
- If you are using `poll`/`poll_one`/`run_one` or otherwise manually driving the `io_service` event loop you may need to adjust usage to make sure you are correctly recognizing the "done with work" and "not done but idling / `io_service::work`" cases.
### Is there a way to check the validity of a `connection_hdl`?
Sometimes, not generally though, because there isn’t a way to check if a TCP connection is valid.
You can try upgrading your hdl to a full connection_ptr using `websocketpp::endpoint::get_con_from_hdl`. If this fails, the hdl is definitely invalid. If it succeeds it may or may not be. The only way to tell definitively is to try and send something (either a message or a ping).
If you handle errors from methods like send, ping, close, etc correctly then you shouldn’t have to worry about accidentally sending to dead connections. The send/ping/pong/close methods will set or throw a specific error in the case that you tried to send something but the connection was closed/gone/etc.
### How do I fix the "address is in use" error when trying to restart my server?
Normally, for security purposes, operating systems prevent programs from listening on sockets created by other programs. When your program crashes and restarts, the new instance is a different program from the perspective of the operating system. As such it can’t listen on the socket address/port that the previous program was using until after a timeout occurs to make sure the old program was done with it.
The first step for handling this is to make sure that you provide a method (signal handler, admin websocket message, etc) to perform a clean server shutdown. There is a question elsewhere in this FAQ that describes the steps necessary for this.
The clean close strategy won't help in the case of crashes or other abnormal closures. An option to consider for these cases is the use of the SO_REUSEADDR socket option. This instructs the OS to not request an exclusive lock on the socket. This means that after your program crashes the replacement you start can immediately listen on that address/port combo again.
__Please note__: how this works exactly depends on your operating system. Additionally, not exclusively locking your listening socket could allow hijacking by other programs if you are running in a shared resource environment. For development this is generally no problem. For a production environment, think carefully about the security model. `websocketpp::transport::asio::endpoint::set_reuse_addr` is the method to do this. You must specify this setting before calling `websocketpp::transport::asio::endpoint::listen`.
### How do I send and recieve binary messages?
When supported by the remote endpoint, WebSocket++ allows reading and sending messages in the two formats specified in RFC6455, UTF8 text and binary. WebSocket++ performs UTF8 validation on all outgoing text messages to ensure that they meet the specification. Binary messages do not have any additional processing and their interpretation is left entirely to the library user.
To determine the type of an incoming message, use `websocketpp::message_buffer::message::get_opcode`. The relevant return values are `websocketpp::frame::opcode::text` and `websocketpp::frame::opcode::binary`. There is no difference in how payloads are retrieved between these modes, only in how WebSocket++ validated the contents and how the library user is to interpret the data.
To specify the type of an outgoing message, use the frame opcode values listed above as the second op parameter for `websocketpp::connection::send`. There are two relevant overloads of send. One that takes a `std::string` and defaults to op=text. The other that takes a `void const *` and a `size_t` length and defaults to op=binary. Note: You can send binary messages via the string overload and text messages via the void * overload. In the case that you are manually building a message buffer rather than using the automatic send member functions, you can pass the opcode in as a parameter to the message buffer constructor or user the `websocketpp::message_buffer::message::set_opcode` member function to set or re-set it later.
## Dependency Management
### Can WebSocket++ be used without Boost?
Yes. WebSocket++ only uses Boost features as polyfills for C++11 language features and libraries. If you have a C++11 compiler and standard library you can use WebSocket++ without Boost. In most cases setting your build environment to use the C++11 (or later) language dialect is sufficient to enable this mode of use.
With less common compilers (and sometimes very recently release compilers) there may be specific issues with certain libraries that aren't automatically detected by the library. For these situations there are additional defines available to fine tune which C++11 libraries and features are used. TODO: more details about them.
For the iostream/raw transport the C++11 standard library is sufficient. For the Asio based transports, there is no C++11 library that provides the networking capabilaties that Asio does. As such even with a C++11 build system, you will need a standalone copy of Asio to use if Boost Asio is not available.
MinGW users who want to avoid Boost should also consult the nearby question about MinGW compatibility.
### Can WebSocket++ be used with standalone Asio
Yes. The process is the same as used with standalone Asio itself. Define `ASIO_STANDALONE` before including Asio or WebSocket++ headers. You will need to download a copy of the Asio headers separately (http://www.think-async.com) and make sure they are in your build system's include path.
### Can WebSocket++ be used without TLS or OpenSSL?
Yes. When using the iostream/raw transport, there are no TLS features and OpenSSL is not required. When using the Asio transport TLS features are optional. You only need OpenSSL if you want to use TLS. You can only make or recieve encrypted connections (https/wss) if you have enabled TLS features.
Whether an Asio endpoint uses TLS or not is determined by its config template parameter. The default bundled `websocketpp::config::asio` and `websocketpp::config::asio_client` configs do not support TLS, the `websocketpp::config::asio_tls` and `websocketpp::config::asio_tls_client` do.
The `<websocketpp/config/asio.hpp>` and `<websocketpp/config/asio_client.hpp>` headers will include both the TLS and non-TLS varients of their respective configs and require the presence of OpenSSL. The `<websocketpp/config/asio_no_tls.hpp>` and `<websocketpp/config/asio_no_tls_client.hpp>` headers will include only the non-TLS configs and do not require OpenSSL.
### Build issues with TLS on recent versions of OS X
Mac OS X ships a severely outdated version of the OpenSSL library. To securely use TLS with WebSocket++ on OS X you will need to install a modern version of OpenSSL via homebrew or compiling from source.
### Can WebSocket++ be used with MinGW
Generally, yes. Note that in C++11 mode MinGW does not currently support the C++11 STL `<thread>` library. WebSocket++ requires a thread/mutex library. Options include Boost thread (the default when a compatible C++11 `<thread>` can't be found) or `mingw-std-threads` (https://github.com/meganz/mingw-std-threads) by including those headers and defining `_WEBSOCKETPP_MINGW_THREAD_`.
## Compression
### How do I use permessage-deflate in version 0.6.0-permessagedeflate and 0.7.0?
These versions of the library require a custom config to use the permessage-deflate extension. Here is a minimal example of such a custom config. You can also integrate these lines into an existing custom config.
Note that in these versions there is no fine grained control over which connections are compressed or not. Clients will request compression with the default settings and use it if the server supports it. Servers will accept whatever parameters clients request.
Outgoing messages by default will be compressed if compression was auto-negotiated during the handshake. There is an option to force a specific message to be sent uncompressed even if compression was negotiated. This may be useful for sending data that you know to be compressed already (images, zip files, etc).
__Server Example__
```
#include <websocketpp/extensions/permessage_deflate/enabled.hpp>
struct deflate_server_config : public websocketpp::config::asio {
// ... additional custom config if you need it for other things
/// permessage_compress extension
struct permessage_deflate_config {};
typedef websocketpp::extensions::permessage_deflate::enabled
<permessage_deflate_config> permessage_deflate_type;
};
typedef websocketpp::server<deflate_server_config> server_endpoint_type;
```
__Client Example__
```
#include <websocketpp/extensions/permessage_deflate/enabled.hpp>
struct deflate_client_config : public websocketpp::config::asio_client {
// ... additional custom config if you need it for other things
/// permessage_compress extension
struct permessage_deflate_config {};
typedef websocketpp::extensions::permessage_deflate::enabled
<permessage_deflate_config> permessage_deflate_type;
};
typedef websocketpp::client<deflate_client_config> client_endpoint_type;
```
## Security
### Is it possible to terminate a malicious connection quickly, without tying up resources performing clean close steps,
Yes. The library will automatically detect and terminate connections that violate the WebSocket protocol. In cases where the library believes the remote endpoint to be malicious or sufficiently broken to be unlikely to understand or process the closing handshake, it will be omited.
If your application detects conditions above the protocol level that you believe to be malicious, for example, if you recognize an IP from a known denial of service attack, you can close the connection with two different levels of urgency. Use the standard `websocketpp::endpoint::close` or `websocketpp::connection::close` methods with one of the following special close codes:
- `websocketpp::close::status::omit_handshake`: Omits the closing handshake, but cleanly closes the TCP connection.
- `websocketpp::close::status::force_tcp_drop`: Forcibly drop the TCP connection.
Please note that usage of these disconnect methods results in a violation of the WebSocket protocol and may have negative reprocusions for the remote endpoint with respect to network timeouts. Please use caution when using them.
## Build Issues
### Getting compile errors related to `std::chrono`, `boost::chrono`, `waitable_timer`, or `steady_clock`
Your build system may be confused about whether it is supposed to be using `boost::chrono` or `std::chrono`. Boost automatically detects this setup on some compilers but not others. Defining `BOOST_ASIO_HAS_STD_CHRONO` can help. See http://www.boost.org/doc/libs/1_60_0/doc/html/boost_asio/overview/cpp2011/chrono.html for more details.
*/

27
third_party/socket.io-client-cpp/lib/websocketpp/docs/getting_started.dox vendored Normal file
View File

@@ -0,0 +1,27 @@
/** \page getting_started Getting Started
WebSocket++ code is available on github at https://github.com/zaphoyd/websocketpp
The official project homepage lives at http://www.zaphoyd.com/websocketpp
The git repository is organized into several directories:
- **docs**: This documentation
- **examples**: Example programs that demonstrate how to build basic versions of some commonly used patterns for WebSocket clients and servers.
- **test**: Unit tests that confirm that the code you have works properly and help detect platform specific issues.
- **tutorials**: Detailed walkthroughs of a select set of the example programs.
- **websocketpp**: All of the library code and default configuration files.
WebSocket++ is a header only library. You can start using it by including the websocketpp source directory in your project's include path and including the appropriate WebSocket++ headers in your program. You may also need to include and/or link to appropriate Boost/system libraries. TODO: More information: Building a program with WebSocket++, Walkthroughs of the example programs
WebSocket++ includes cmake and scons scripts for building the examples and unit tests. Neither system is needed unless you want to build tests or examples in an automated fashion.
__Usage questions__ should be posted to the project mailing list at http://groups.google.com/group/websocketpp/ or the IRC channel (\#websocketpp on freenode).
__Bugs and issues__ should be posted to the project GitHub issues queue: https://github.com/zaphoyd/websocketpp/issues.
__Pull requests__ on GitHub are welcome. Please make them against the `develop` branch.
WebSocket++ is written and maintained by Peter Thorson. You can contact me via GitHub messaging, IRC, or via email at websocket@zaphoyd.com.
*/

165
third_party/socket.io-client-cpp/lib/websocketpp/docs/handlers.dox vendored Normal file
View File

@@ -0,0 +1,165 @@
/** \page reference.handlers Handler Reference
Handlers allow WebSocket++ programs to receive notifications about events
that happen in relation to their connections. Some handlers also behave as
hooks that give the program a chance to modify state or adjust settings before
the connection continues.
Handlers are registered by calling the appropriate `set_*_handler` method on either an
endpoint or connection. The * refers to the name of the handler (as
specified in the signature field below). For example, to set the open handler,
call `set_open_handler(...)`.
Setting handlers on an endpoint will result in them being copied as the default
handler to all new connections created by that endpoint. Changing an endpoint's
handlers will not affect connections that are already in progress. This includes
connections that are in the listening state. As such, it is important to set any
endpoint handlers before you call `endpoint::start_accept` or else the handlers
will not be attached to your first connection.
Setting handlers on a connection will result in the handler being changed for
that connection only, starting at the next time that handler is called. This can
be used to change the handler during a connection.
Connection Handlers
-------------------
These handlers will be called at most once per connection in the order specified below.
### Socket Init Handler
| Event | Signature | Availability |
| --------------------- | ----------------------------------------------------- | -------------------- |
| Socket initialization | `socket_init(connection_hdl, asio::ip::tcp::socket&)` | 0.3.0 Asio Transport |
This hook is triggered after the socket has been initialized but before a connection is established.
It allows setting arbitrary socket options before connections are sent/recieved.
### TCP Pre-init Handler
| Event | Signature | Availability |
| ----------------------------- | ------------------------------ | -------------------- |
| TCP established, no data sent | `tcp_pre_init(connection_hdl)` | 0.3.0 Asio Transport |
This hook is triggered after the TCP connection is established, but before any pre-WebSocket-handshake
operations have been run. Common pre-handshake operations include TLS handshakes and proxy connections.
### TCP Post-init Handler
| Event | Signature | Availability |
| ----------------------- | ------------------------------------------ | ----------------------------- |
| Request for TLS context | `tls_context_ptr tls_init(connection_hdl)` | 0.3.0 Asio Transport with TLS |
This hook is triggered before the TLS handshake to request the TLS context to use. You must
return a pointer to a configured TLS conext to continue. This provides the opportuinity to
set up the TLS settings, certificates, etc.
### Validate Handler
| Event | Signature | Availability |
| ------------------------------------- | ------------------------------- | ---------------------------- |
| Hook to accept or reject a connection | `bool validate(connection_hdl)` | 0.3.0 Core, Server role only |
This hook is triggered for servers during the opening handshake after the request has been
processed but before the response has been sent. It gives a program the opportunity to inspect
headers and other connection details and either accept or reject the connection. Validate happens
before the open or fail handler.
Return true to accept the connection, false to reject. If no validate handler is registered,
all connections will be accepted.
### Open Connection Handler
| Event | Signature | Availability |
| ------------------------- | ---------------------- | ------------ |
| Successful new connection | `open(connection_hdl)` | 0.3.0 Core |
Either open or fail will be called for each connection. Never both. All
connections that begin with an open handler call will also have a matching
close handler call when the connection ends.
### Fail Connection Handler
| Event | Signature | Availability |
| ----------------------------------- | ---------------------- | ------------ |
| Connection failed (before opening) | `fail(connection_hdl)` | 0.3.0 Core |
Either open or fail will be called for each connection. Never both. Connections
that fail will never have a close handler called.
### Close Connection Handler
| Event | Signature | Availability |
| --------------------------------- | ----------------------- | ------------ |
| Connection closed (after opening) | `close(connection_hdl)` | 0.3.0 Core |
Close will be called exactly once for every connection that open was called for.
Close is not called for failed connections.
Message Handlers
----------------
These handers are called in response to incoming messages or message like events. They only will be called while the connection is in the open state.
### Message Handler
| Event | Signature | Availability |
| --------------------- | -------------------------------------- | ------------ |
| Data message recieved | `message(connection_hdl, message_ptr)` | 0.3.0 Core |
Applies to all non-control messages, including both text and binary opcodes. The
`message_ptr` type and its API depends on your endpoint type and its config.
### Ping Handler
| Event | Signature | Availability |
| ------------- | ---------------------------------------- | ------------ |
| Ping recieved | `bool ping(connection_hdl, std::string)` | 0.3.0 Core |
Second (string) argument is the binary ping payload. Handler return value
indicates whether or not to respond to the ping with a pong. If no ping handler
is set, WebSocket++ will respond with a pong containing the same binary data as
the ping (Per requirements in RFC6455).
### Pong Handler
| Event | Signature | Availability |
| ------------- | ----------------------------------- | ------------ |
| Pong recieved | `pong(connection_hdl, std::string)` | 0.3.0 Core |
Second (string) argument is the binary pong payload.
### Pong Timeout Handler
| Event | Signature | Availability |
| ---------------------------------- | ------------------------------------------- | ---------------------------------------- |
| Timed out while waiting for a pong | `pong_timeout(connection_hdl, std::string)` | 0.3.0 Core, transport with timer support |
Triggered if there is no response to a ping after the configured duration. The second
(string) argument is the binary payload of the unanswered ping.
### HTTP Handler
| Event | Signature | Availability |
| --------------------- | --------------------- | ---------------------------- |
| HTTP request recieved | `http(connection_hdl` | 0.3.0 Core, Server role only |
Called when HTTP requests that are not WebSocket handshake upgrade requests are
recieved. Allows responding to regular HTTP requests. If no handler is registered
a 426/Upgrade Required error is returned.
### Interrupt Handler
| Event | Signature | Availability |
| ----------------------------------- | --------------------------- | ------------ |
| Connection was manually interrupted | `interrupt(connection_hdl)` | 0.3.0 Core |
Interrupt events can be triggered by calling `endpoint::interrupt` or `connection::interrupt`.
Interrupt is similar to a timer event with duration zero but with lower overhead. It is useful
for single threaded programs to allow breaking up a very long handler into multiple parts and
for multi threaded programs as a way for worker threads to signale to the main/network thread
that an event is ready.
todo: write low and high watermark handlers
*/

102
third_party/socket.io-client-cpp/lib/websocketpp/docs/logging.dox vendored Normal file
View File

@@ -0,0 +1,102 @@
/** \page reference.logging Logging Reference
WebSocket++ has the capability of logging events during the lifetime of the connections that it processes. Each endpoint has two independent logging interfaces that are used by all connections created by that endpoint. The first is an access interface that allows logging routine events in the life of a connection (such as connect/disconnect and receipt of messages). The other is an error interface that allows logging non-routine problems or errors. Each interface has a number of different named channels that can be toggled on and off independently.
Exactly how these logs are processed and where they are written to depends on which logging policy is in use. Several logging policies are included by default and you can write your own policy if you need something more specialized. Selecting a policy is done via the \subpage reference.config "endpoint config".
Common functionality (all policies)
-----------------------------------
### Logging Channels
Each logging interface is divided into 32 named channels. Log messages are written to a specific interface on a specific channel. Which log messages are actually printed is determined by which channels are enabled or not. Channels can be enabled or disabled either at compile time or at runtime.
### Enabling and Disabling Channels
Channels disabled at compile time are removed from the code entirely (assuming correct compiler optimization settings) and are not available for runtime enabling or disabling. To disable channels at compile time, use the `alog_level` and `elog_level` values within your \subpage reference.config "endpoint config". Channels not disabled at compile time can be enabled or disabled at runtime using the `websocketpp::endpoint::set_access_channels()`, `websocketpp::endpoint::clear_access_channels()`, `websocketpp::endpoint::set_error_channels()`, and `websocketpp::endpoint::clear_error_channels()` methods.
The set and clear functions act only on the channels specified. `set_access_channels(log::alevel::connect)` will enable logging of new connections. Following this with `set_access_channels(log::alevel::disconnect)` will enable logging of disconnections in addition to connections. Use `clear*` functions to disable a specific channel. Channels may be combined using bitwise operations to create aggregate packages of channels that may be set or cleared at once. Default packages include `websocketpp::log::alevel::all`, `websocketpp::log::elevel::all`, `websocketpp::log::alevel::none`, `websocketpp::log::elevel::none`. These represent all possible access/error channels and no access/error channels respectively. For convenience, setting none is aliased to clearing all.
### Examples
__Disable all__
`clear_access_channels(log::alevel::all)`
__Disable all (alternative method)__
`set_access_channels(log::alevel::none)`
__Multiple channels at once__
`log::alevel::message_payload | log::alevel::message_payload`
__All except one__
`log::alevel::all ^ log::alevel::message_payload`
__Default settings__
By default, only debug/development logging is disabled.
### Access to underlying loggers
Logging interfaces may be directly accessed via their associated endpoint or connection using get_alog() and get_elog(). This allows access to methods specific to the chosen logging policy.
Basic Logging (Default Policy)
------------------------------
The basic logging policy (`websocketpp::log::basic`) writes logs to a std::ostream. By default, access logs are written to stdout and error logs are written to stderr. Each logging interface may be optionally redirected to an arbitrary C++ stream (including file streams) using the `websocketpp::log::basic::set_ostream()` method.
Syslog Logging
--------------
The syslog logging policy (`websocketpp::log::syslog`) logs to POSIX syslog. It is included in the header `<websocketpp/logger/syslog.hpp>`. It requires a system with `<syslog.h>`.
Stub Logging
------------
The stub logging policy (`websocketpp::log::stub`) implements the logging policy interface but ignores all input and provides no output. It can be used to stub out the logging system in tests or to completely disable and remove nearly all logging related code.
The stub logger also provides documentation for the minimal required interface to build a custom logging policy.
Log level reference
-------------------
### Error Logging Levels
Each of these channels is in the namespace `websocketpp::log::elevel`
| Level | Description |
| ------- | -------------------------------------------------------------------------------------------------------------------------- |
| none | Special aggregate value representing "no levels" |
| devel | Low level debugging information (warning: very chatty). Requires debug or custom config. |
| library | Information about unusual system states or other minor internal library problems, less chatty than devel. |
| info | Information about minor configuration problems or additional information about other warnings. |
| warn | Information about important problems not severe enough to terminate connections. |
| rerror | Recoverable error. Recovery may mean cleanly closing the connection with an appropriate error code to the remote endpoint. |
| fatal | Unrecoverable error. This error will trigger immediate unclean termination of the connection or endpoint. |
| all | Special aggregate value representing "all levels" |
### Access Logging Levels
Each of these channels is in the namespace `websocketpp::log::alevel`
| Level | Description |
| --------------- | -------------------------------------------------------------------------------------------------- |
| none | Special aggregate value representing "no levels" |
| connect | One line for each new connection that includes a host of information including: the remote address, websocket version, requested resource, http code, remote user agent |
| disconnect | One line for each connection that is closed. Includes closing codes and reasons |
| control | One line per control message |
| frame_header | One line per frame, includes the full frame header |
| frame_payload | One line per frame, includes the full message payload (warning: lots of output for large messages) |
| message_header | Reserved |
| message_payload | Reserved |
| endpoint | Reserved |
| debug_handshake | Extra information about opening handshakes |
| debug_close | Extra information about closing handshakes |
| devel | Development messages (warning: very chatty). Requires debug or custom config. |
| app | Special channel for application specific logs. Not used by the library. |
| all | Special aggregate value representing "all levels" |
*/

22
third_party/socket.io-client-cpp/lib/websocketpp/docs/manual.css vendored Normal file
View File

@@ -0,0 +1,22 @@
.tabs, .tabs2, .tabs3, .navpath ul {
background-image: none;
background-color: #333;
border: none;
border-bottom: 1px solid #575757;
}
.tablist li, .navpath li {
background-image: none;
background-color: #333;
}
.tablist a, .navpath li.navelem a {
color: #ccc;
text-shadow: 0px 1px 1px black;
}
.tablist a:hover, .navpath li.navelem a:hover {
background-image: none;
background-color: #444;
color: #ccc;
}

23
third_party/socket.io-client-cpp/lib/websocketpp/docs/manual.dox vendored Normal file
View File

@@ -0,0 +1,23 @@
/** \mainpage
WebSocket++ is a C++ library that can be used to implement WebSocket functionality. The goals of the project are to provide a WebSocket implementation that is portable, flexible, lightweight, low level, and high performance.
WebSocket++ does not intend to be used alone as a web application framework or full featured web services platform. As such the components, examples, and performance tuning are geared towards operation as a WebSocket client or server. There are some minimal convenience features that stray from this (for example the ability to respond to HTTP requests other than WebSocket Upgrades) but these are not the focus of the project. In particular WebSocket++ does not intend to implement any non-WebSocket related fallback options (ajax / long polling / comet / etc).
In order to remain compact and improve portability, the WebSocket++ project strives to reduce or eliminate external dependencies where possible and appropriate. WebSocket++ core has no dependencies other than the C++11 standard library. For non-C++11 compilers the Boost libraries provide drop in polyfills for the C++11 functionality used.
WebSocket++ implements a pluggable data transport component. The default component allows reduced functionality by using STL iostream or raw byte shuffling via reading and writing char buffers. This component has no non-STL dependencies and can be used in a C++11 environment without Boost. Also included is an Asio based transport component that provides full featured network client/server functionality. This component requires either Boost Asio or a C++11 compiler and standalone Asio. As an advanced option, WebSocket++ supports custom transport layers if you want to provide your own using another library.
In order to accommodate the wide variety of use cases WebSocket++ has collected, the library is built in a way that most of the major components are loosely coupled and can be swapped out and replaced. WebSocket++ will attempt to track the future development of the WebSocket protocol and any extensions as they are developed.
- \subpage getting_started "Getting Started"
- \subpage faq "FAQ"
- \subpage tutorials "Tutorials"
- \subpage md_changelog "Change Log / Version History"
- Reference
- \subpage reference.handlers "Handler Reference"
- \subpage reference.config "Config Reference"
- \subpage reference.logging "Logging Reference"
*/

52
third_party/socket.io-client-cpp/lib/websocketpp/docs/simple_broadcast_server.cpp vendored Normal file
View File

@@ -0,0 +1,52 @@
#include <set>
#include <websocketpp/config/asio_no_tls.hpp>
#include <websocketpp/server.hpp>
typedef websocketpp::server<websocketpp::config::asio> server;
using websocketpp::connection_hdl;
using websocketpp::lib::placeholders::_1;
using websocketpp::lib::placeholders::_2;
using websocketpp::lib::bind;
class broadcast_server {
public:
broadcast_server() {
m_server.init_asio();
m_server.set_open_handler(bind(&broadcast_server::on_open,this,::_1));
m_server.set_close_handler(bind(&broadcast_server::on_close,this,::_1));
m_server.set_message_handler(bind(&broadcast_server::on_message,this,::_1,::_2));
}
void on_open(connection_hdl hdl) {
m_connections.insert(hdl);
}
void on_close(connection_hdl hdl) {
m_connections.erase(hdl);
}
void on_message(connection_hdl hdl, server::message_ptr msg) {
for (auto it : m_connections) {
m_server.send(it,msg);
}
}
void run(uint16_t port) {
m_server.listen(port);
m_server.start_accept();
m_server.run();
}
private:
typedef std::set<connection_hdl,std::owner_less<connection_hdl>> con_list;
server m_server;
con_list m_connections;
};
int main() {
broadcast_server server;
server.run(9002);
}

65
third_party/socket.io-client-cpp/lib/websocketpp/docs/simple_count_server_thread.cpp vendored Normal file
View File

@@ -0,0 +1,65 @@
#include <functional>
#include <mutex>
#include <set>
#include <thread>
#include <websocketpp/config/asio_no_tls.hpp>
#include <websocketpp/server.hpp>
typedef websocketpp::server<websocketpp::config::asio> server;
using websocketpp::connection_hdl;
class count_server {
public:
count_server() : m_count(0) {
m_server.init_asio();
m_server.set_open_handler(bind(&count_server::on_open,this,_1));
m_server.set_close_handler(bind(&count_server::on_close,this,_1));
}
void on_open(connection_hdl hdl) {
std::lock_guard<std::mutex> lock(m_mutex);
m_connections.insert(hdl);
}
void on_close(connection_hdl hdl) {
std::lock_guard<std::mutex> lock(m_mutex);
m_connections.erase(hdl);
}
void count() {
while (1) {
sleep(1);
m_count++;
std::stringstream ss;
ss << m_count;
std::lock_guard<std::mutex> lock(m_mutex);
for (auto it : m_connections) {
m_server.send(it,ss.str(),websocketpp::frame::opcode::text);
}
}
}
void run(uint16_t port) {
m_server.listen(port);
m_server.start_accept();
m_server.run();
}
private:
typedef std::set<connection_hdl,std::owner_less<connection_hdl>> con_list;
int m_count;
server m_server;
con_list m_connections;
std::mutex m_mutex;
};
int main() {
count_server server;
std::thread t(std::bind(&count_server::count,&server));
server.run(9002);
}

10
third_party/socket.io-client-cpp/lib/websocketpp/docs/tutorials.dox vendored Normal file
View File

@@ -0,0 +1,10 @@
/** \page tutorials Tutorials
These tutorials are works in progress, some are more complete than others.
- \subpage md_tutorials_utility_client_utility_client
- \subpage md_tutorials_utility_server_utility_server
- \subpage md_tutorials_broadcast_tutorial_broadcast_tutorial
- \subpage md_tutorials_chat_tutorial_chat_tutorial
*/