OnePush is message pushing service in Yahoo for many important Yahoo service, like Yahoo Mail, Yahoo Finance and etc.
API / Routing: 20 servers / colo, 4000 RPS / server (8 core CUP, 16G Memory / server)
Connection Server: 100 servers / colo, 200k connection / server
Deliver: 100 servers / colo for HBase
The notifications are delivered to iOS devices through APNS (Apple Push Notification Service).
The notifications are delivered to Android devices which have Android Push Agent installed.
Mock server: support telnet, debug on, debug off, lightweight, cs, Boost Async IO, mock response. handler, status, set timer.
Mock device: Boost Async IO, support telnet, massive links, mock request. Pretty more request
We use boost io to do the mock job.
SBT->excel case, library, service->JMS client, JMS server, HBase
The Boost.Asio library is intended for programmers using C++ for systems programming, where access to operating system functionality such as networking is often required. In particular, Boost.Asio addresses the following goals: Portability, Scalability, Efficiency, Model concepts from established APIs, Ease of use, Basis for further abstraction.
We shall start by examining synchronous operations.
The io_service represents your program’s link to the operating system’s I/O
To perform I/O operations your program will need an I/O object such as a TCP socket:
initiates the connect operation by calling the I/O object:
The I/O object forwards the request to the
io_servicecalls on the operating system to perform the connect operation.
The operating system returns the result of the operation to the
io_servicetranslates any error resulting from the operation into an object of type
boost::system::error_code. An error_code may be compared with specific values, or tested as a boolean (where a false result means that no error occurred). The result is then forwarded back up to the I/O object.
The I/O object throws an exception of type
boost::system::system_errorif the operation failed. If the code to initiate the operation had instead been written as:
When an asynchronous operation is used, a different sequence of events occurs.
Your program initiates the connect operation by calling the I/O object:
where your_completion_handler is a function or function object with the signature:
void your_completion_handler(const boost::system::error_code& ec);
The exact signature required depends on the asynchronous operation being performed. The reference documentation indicates the appropriate form for each operation.
The I/O object forwards the request to the
io_servicesignals to the operating system that it should start an asynchronous connect.
Time passes. (In the synchronous case this wait would have been contained entirely within the duration of the connect operation.)
The operating system indicates that the connect operation has completed by placing the result on a queue, ready to be picked up by the
Your program must make a call to
io_service::run()(or to one of the similar
io_servicemember functions) in order for the result to be retrieved. A call to
io_service::run()blocks while there are unfinished asynchronous operations, so you would typically call it as soon as you have started your first asynchronous operation.
While inside the call to
io_servicedequeues the result of the operation, translates it into an error_code, and then passes it to your completion handler.
Proactor design pattern is implemented in Boost.Asio, without reference to platform-specific details.
Multiple threads may call
io_service::run() to set up a pool of threads from which completion handlers may be invoked. This approach may also be used with
io_service::post() to use a means to perform any computational tasks across a thread pool. Consequently, it is the library user’s responsibility to create and manage all threads to which the notifications will be delivered.
A strand is defined as a strictly sequential invocation of event handlers (i.e. no concurrent invocation). Boost.Asio implements the Proactor design pattern in terms of a Reactor, such as select, epoll or queue Boost.Asio includes support for scatter-gather operations. These operations involve one or more buffers:
A scatter-read receives data into multiple buffers.
A gather-write transmits multiple buffers.
Many I/O objects in Boost.Asio are stream-oriented. This means that: there are no message boundaries. The data being transferred is a continuous sequence of bytes. Read or write operations may transfer fewer bytes than requested. This is referred to as a short read or short write.
Many asynchronous operations need to allocate an object to store state associated with the operation.
To aid in debugging asynchronous programs, Boost.Asio provides support for handler tracking. When enabled by defining
BOOST_ASIO_ENABLE_HANDLER_TRACKING, Boost.Asio writes debugging output to the standard error stream
The Boost.Asio library includes a low-level socket interface based on the BSD socket API, which is widely implemented and supported by extensive literature.
Long running I/O operations will often have a deadline by which they must have completed.
Boost.Asio includes classes for creating and manipulating serial ports in a portable manner.
serial_port port(my_io_service, name); where name is something like “COM1” on Windows, and “/dev/ttyS0” on POSIX platforms.
Boost.Asio supports signal handling using a class called signal_set.
Boost.Asio contains classes and class templates for basic SSL support. These classes allow encrypted communication to be layered on top of an existing stream, such as a TCP socket.
asynchronous non-blocking I/O model is one of overlapping processing with I/O. The read request returns immediately, indicating that the read was successfully initiated