| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This introduces enough of the HTTP API to support fully server
applications, including creation of websocket style protocols,
pluggable handlers, and so forth.
We have also introduced scatter/gather I/O (rudimentary) for
aios, and made other enhancements to the AIO framework. The
internals of the AIOs themselves are now fully private, and we
have eliminated the aio->a_addr member, with plans to remove the
pipe and possibly message members as well.
A few other minor issues were found and fixed as well.
The HTTP API includes request, response, and connection objects,
which can be used with both servers and clients. It also defines
the HTTP server and handler objects, which support server applications.
Support for client applications will require a client object to be
exposed, and that should be happening shortly.
None of this is "documented" yet, bug again, we will follow up shortly.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This makes the APIs use string keys, and largely eliminates the use of
integer option IDs altogether. The underlying registration for options
is also now a bit richer, letting protcols and transports declare the
actual options they use, rather than calling down into each entry point
carte blanche and relying on ENOTSUP.
This code may not be as fast as the integers was, but it is more intuitive,
easier to extend, and is not on any hot code paths. (If you're diddling
options on a hot code path you're doing something wrong.)
|
| |
|
|
|
|
|
|
|
|
| |
This fleshes most of the pipe API out, making it available to end user
code. It also adds a URL option that is independent of the address
options (which would be sockaddrs.)
Also, we are now setting the pipe for req/rep. The other protocols need
to have the same logic added to set the receive pipe on the message. (Pair
is already done.)
|
| |
|
|
|
|
|
|
|
|
|
| |
fixes #66 Make pipe and endpoint structures private
This changes a number of things, refactoring endpoints and supporting
code to keep their internals private, and making endpoint close
synchronous. This will allow us to add a consumer facing API for
nng_ep_close(), as well as property APIs, etc.
While here a bunch of convoluted and dead code was cleaned up.
|
| |
|
|
|
|
|
|
| |
The problem is that reaping these things performs some blocking
operations which can tie up slots in the taskq, preventing other
tasks from running. Ultimately this can lead to a deadlock as
tasks that are blocked wind up waiting for tasks that can't get
scheduled. Blocking tasks really should not run on the system taskq.
|
| |
|
|
|
|
|
| |
The queue is bound at initialization time of the task, and we call
entries just tasks, so we don't have to pass around a taskq pointer
across all the calls. Further, nni_task_dispatch is now guaranteed
to succeed.
|
| | |
|
| |
|
|
|
|
|
| |
This cleans up the pipe creation logic greatly, and eliminates
a nasty potential deadlock (lock-order incorrect.) It also
adds a corret binary exponential and randomized backoff on both
accept and connect.
|
| |
|
|
|
|
| |
This logic leaves a race condition in the dial side, which will
be fixed with a subsequent change to convert that to fully asynchronous
as well.
|
| | |
|
| |
|
|
|
|
| |
This means that pipe_start always succeeds, and we can guarantee that
the pipe_start_cb is always executed, and in another context. This may help
when we need to change the way that sockets and endpoints are associated.
|
| | |
|
| |
|
|
|
|
| |
This prevents a slow partner from blocking new connections from being
established on the server. Before this a single partner could cause
the server to block waiting to complete the negotiation.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This should eliminate all need for protocols to do their own
thread management tasks.
|
| |
|
|
|
|
|
|
|
| |
In an attempt to simplify the protocol implementation, and hopefully
track down a close related race, we've made it so that most protocols
need not worry about locks, and can access the socket lock if they do
need a lock. They also let the socket manage their workers, for the
most part. (The req protocol is special, since it needs a top level
work distributor, *and* a resender.)
|
| | |
|
| |
|
|
|
| |
This also adds checks in the protocols to verify that pipe peers
are of the proper protocol.
|
| |
|
|
|
|
|
| |
This uncovered a few problems - inproc was not moving the headers
to the body on transmit, and the message chunk allocator had a serious
bug leading to memory corruption. I've also added a message dumper,
which turns out to be incredibly useful during debugging.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This may also address a race in closing down pipes. Now pipes are always
registered with the socket. They also always have both a sender and receiver
thread. If the protocol doesn't need one or the other, the stock thread just
exits early.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
At this point listening and dialing operations appear to function properly.
As part of this I had to break the close logic up since otherwise we had a
loop trying to reap a thread from itself. So there is now a separate reaper
thread for pipes per-socket. I also changed lists to be a bit more rigid,
and allocations now zero memory initially. (We had bugs due to uninitialized
memory, and rather than hunt them all down, lets just init them to sane zero
values.)
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
