| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* adds nng_dialer_start_aio
This change adds `nng_dialer_start_aio` (if you have a better name, I'm
happy to change it), whose docs read:
> `nng_dialer_start_aio` starts the endpoint dialing asynchronously.
> This is only possible if the dialer is not already dialing. Unlike
> `nng_dialer_start`, this accepts an AIO such that the caller can learn
> when the dialing eventually succeeds or fails. The supplied AIO must
> have been initialized, and is only triggered with the result of the
> first dial attempt.
This new function makes it possible for applications to perform a
non-blocking dial, but still later be notified of the result of that
dial. Arguably, this obviates the need for `NNG_FLAG_NONBLOCK` in
`dialer_start` altogether, but no need to break backwards compatibility.
There is technically a functional change here, which is that the
"Starting dialer for socket" message now gets printed _before_ the dial
is complete in the blocking case, rather than after. It's possible to
change this if we're willing to make the code slightly more complicated,
but given it says "Starting", not "Started", this change felt fine.
|
| |
|
| |
Modify the unmatched brackets in the sample code
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This is not yet fully complete, but it's most of the content.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
While here addressed some minor issues with http docs as well.
|
| | |
|
| |
|
|
|
|
| |
This replaces the int, and we will expand this further, as this
makes it clear that the int is actually an error code and helps in
debuggers that can provide symbolic values.
|
| |
|
|
| |
The data is now passed directly to the handler function.
|
| | |
|
| | |
|
| |
|
|
|
| |
Nothing really needs it -- we kept it in 1.0 to preserve semantics,
but there is no requirement for semantic preservation in 2.0.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This represents a major change in the HTTP code base, consisting
of a complete revamp of the HTTP API. The changes here are too
numerous to mention, but the end result should be a vastly
simpler API for both server and client applications.
Many needless allocations were removed by providing fixed buffers
for various parameters and headers when possible.
A few bugs were fixed. Most especially we have fixed some bugs
around very large URIs and headers, and we have also addressed
conformance bugs to more closely conform to RFCs 9110 and 9112.
As part of this work, the APIs for WebSockets changed slightly
as well. In particular the properties available for accessing
headers have changed.
There is still documentation conversion work to do, and additional
functionality (such as proper support for chunked transfers), but
this is a big step in the right direction.
|
| |
|
|
|
|
|
|
|
|
| |
This simplified API lets callbacks obtain the response from the
connection objection directly, and does not require the aio to carry
it as a parameter. Further, the request and response are both
stored inline in the connection, reducing allocations.
This is at present only for the server; the client will get a similar
set of changes.
|
| |
|
|
|
|
|
|
| |
The API is identical, except that some names have changed, and this is now a
header library in `nng/args.h` - so the core library does not need to carry this
code in binaries. Being a header library also means it is not necessary to
link against NNG, and it does not include any parts of NNG; it only depends on
a standard C99 or C11 environment.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This aligns more closely with the nng_ctx functions.
|
| | |
|
| | |
|
| |
|
|
| |
This makes it work better with different mdbook color schemes.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Also, clarification and add socket option docs for MAXRECVSZ, RECONNMINT, RECONNMAXT
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
This flag failed to provide real zero copy that it was intended for,
and it also involved extra allocations. Further, the API for it was
brittle and error prone.
Modern code should just work directly with nng_msg structures.
|
| |
|
|
|
|
| |
Nothing else uses it, and nothing else *should* use it because SHA1 is insecure.
WebSockets have to use it by definition, unfortunately. The implementation is
not very fast, but doesn't have to be for the use case of websocket keying.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|