| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
| |
This is not quite complete, but it sets the stage for other
protocols (such as zmq or mqtt) to be added to the project.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is based on testutil/acutest, but is cleaner and fixes some
short-comings. We will be adding more support for additional
common paradigms to better facilitate transport tests.
While here we added some more test cases, and fixed a possible
symbol collision in the the stats framework (due to Linux use
of a macro definition of "si_value" in a standard OS header).
Test coverage may regress slightly as we are no longer using
some of the legacy APIs.
|
| |
|
|
|
|
|
|
|
|
|
| |
fixes #1160 Consider limiting maximum hop count to 15
fixes #1098 Maximum maxTTL should be compile time defined
This doesn't expose the max-MaxTTL in the CMakeList.txt -- there
is really no reason anyone should be changing it. This does not
yet inline the message header into the nni_msg_t, but it is my
intention to do so soon, and eliminate most of the conditional cases
for failure on inserting into the header.
|
| |
|
|
|
|
|
| |
This only addresses the newly rewitten compat_tcp test, but it
sets the groundwork for the other tests, so that when they are
updated to the new acutest.h they can use the new marry code to
establish connections cleanly and safely.
|
| |
|
|
|
|
|
|
| |
This correctly moves the entire protocol header for XREQ and XRESPONDENT
protocols to the message header (not the body). This is where it should
always have been. There is some small chance that applications which were
coded to parse the header from the body will break. We don't think there
are any such applications in use.
|
|
|
The TTL in these cases should have been atomic. To facilitate
things we actually introduce an atomic int for convenience. We
also introduce a convenience nni_msg_must_append_u32() and
nni_msg_header_must_append_u32(), so that we can eliminate some
failure tests that cannot ever happen. Combined with a new test
for xreq, we have 100% coverage for xreq and more coverage for
the other REQ/REP protocols.
|
