harsath / blueth Goto Github PK

As pointed out by Wez, we can run the both server and the client's thread on the same GTest process. Right now, we use a defined port but we can connect to the port 0 and make the kernel give use the free port.

But first, debug the issue of the SyncNetworkClient not able to connect to the server's thread running in the different thread on the same process.

Right now, the blueth::IOBuffer which does the non-blocking async networking IO is implemented using a owning buffer, which means, if we pass a memory location with it's size, it copies the entire memory block and owns it.

It's a fine process, but it makes copies(which is good, but sometimes bad and hurts performance in cases where copies are trivially not needed).

Let's create a non-owining Mutable and ReadOnly buffers buffer, we expect one to pass the pointer to the memory location and with it's size and we do the operations on the pointer.

• Mutable Buffer
  We expect one to pass a pointer to a memory block which is managed by some other thing, with the current_capacity, current_offset and start_pointer
• Read Only Buffer
  We expect one to pass a pointer to a memory block which is again managed by some other thing, we assume that the life time of the memory block is managed by the thing which created the Read Only Buffer.

Usage of std::shared_ptr on the implementation of the EventLoopBase pure virtual and epoll implementation increases the complexity of testing on the initial phase.

It's better if we start off using a raw pointer and make the next PR for the smart pointer re-write on the parts where we'd need them.

We're currently handling all the exceptions when a syscall throws an error or if a method is unimplemented or the user's supplied argument is invalid.

Ideally, we'd need to have separate exceptions for handling these things. We'll first have to list out all the possible exceptions that're in the range of Blueth(that involves, networking, protocol parsing, syscall error, etc)

It can be used in various places like as an intermediate during the GET request.

LRU cache eviction policy is better for this use case than others out there.

Maybe use std::vector<std::string_view> to represent the frames within the io::IOBuffer<CharType>? Or we use std::vector<std::string> and own those bytes and discard io::IOBuffer<CharType itself(but we only have it for reading from the network socket as a read buffer and later 'move' those bytes off into a LineFrameDecoder to build the std::string?

Currently, we lack good documentation for the things that Blueth contains. We'd need to have a Doxygen documentation for the Blueth just like how we have for other repositories like cap-container and poc-http-parsers and host the documentation on a private server with a publically accessible URL to the Blueth specific root and have a web-hook to update the documentation on the server just like cap-containers.

It's good if we have an interface blueth::HTTP::HTTProxy(proxy_endpoint_ip, proxy_endpoint_port) to use a hosted HTTP proxy using stream like interface to send()/recv() bytes through the HTTPProxy.

Maybe we should make this a blocking/sync byte transfer on the wire. We might use HTTP CONNECT for this one.

Fix the bug on the detached thread wolfSSL-Server for testing

Event loop interface for Plaintext/non-SSL byte transfer stream. We register callbacks for read/write events on the file descriptors and the inserted callbacks get called.

Maybe we can take a template <Callable> which will be sent to a Thread-Pool-Executor for doing the work. The Callable doesn't take any arguments and returns a void since it's an object which has void operator()() implementation, we can just conveniently call it from the Thread-Pool-Executor and do whatever work it has to do.

So, a main/single-thread will listen for all events on the listening socket(s)(if we use REUSE_ADDR so that the Kernel will load balance the traffic) and when an event occurred on a particular FD, we push that onto the EventsQueue and out Thread-Pool-Executor will pop work from that queue and execute it. Once done the FSM's state is in WORK_DONE, we push that onto the FinishedWork queue where that single thread will pop and check if we need to register this FD for read/write/no-event and do it accordingly.

When a networking service needs a graceful config file restart or graceful shutdown of the worker threads or graceful shutdown, we have a specification for the list of signals and how the master process handles those signals by running specific code in the event of the specific signals.

It's better to have some abstraction to handle the code/helper subroutine execution service. The service class takes the list of signals and their callbacks to execute in the event.

It's also good to make the callback with a signature of void fn(Callable). In which we just invoke the callback. We assume that invoked callback doesn't take any arguments and also doesn't return some values which the user might be interested in. If they need to pass a piece of state information, they must have a class with operator()() overload to get around that.

Finally, we have a single method which the user should invoke to activate the signal handler since we don't take all the signal callbacks on the constructor.

We've a void signal_handler::install_callback(signal_type, callable_type) to take the callabcks and a switch-case jump statements to install the callbacks.

switch(signal_type) {
    case signal_type_one:
        callback_one = callback_type;
        return 0;
    case signal_type_two:
        callback_two = callback_type;
        return 0;
    default:
        return -1;