- 24 Feb, 2014 3 commits
-
-
Philip Withnall authored
Ensure the agent’s context doesn’t get iterated while in the middle of reading a message, as that will corrupt the component->recv_messages state.
-
Philip Withnall authored
-
Philip Withnall authored
Use it instead of memcmp() to avoid comparing padding bytes.
-
- 21 Feb, 2014 2 commits
-
-
Olivier Crête authored
-
Olivier Crête authored
-
- 20 Feb, 2014 2 commits
-
-
Olivier Crête authored
-
Olivier Crête authored
-
- 19 Feb, 2014 1 commit
-
-
Olivier Crête authored
-
- 13 Feb, 2014 1 commit
-
-
Olivier Crête authored
-
- 05 Feb, 2014 2 commits
-
-
Olivier Crête authored
Otherwise it ran the "yes" command
-
Olivier Crête authored
It tends to cause false warnings
-
- 31 Jan, 2014 29 commits
-
-
Olivier Crête authored
-
Olivier Crête authored
And we get close to 10% perf boost
-
Olivier Crête authored
Looping through the list of send segment was the only thing from libnice showing up in my profiler. Keeping a list of segment that were never sent has made it disappear.
-
Olivier Crête authored
-
Olivier Crête authored
-
Olivier Crête authored
-
Olivier Crête authored
This is very important for reliable mode. Also use it in the GOutputStream so as to not get into the case where there is still some space in the TCP buffer, but not enough for one message. Also warn against this problem.
-
Olivier Crête authored
Also made the GIOStream into a singleton, it always returns the same one. Also make it impossible to create a GIOStream for a non-existing stream/component
-
Olivier Crête authored
It was used correctly only half the time anyway
-
Olivier Crête authored
We never send multiple messages to separate targets in practice, so this will simplify the code
-
Olivier Crête authored
Otherwise it would have attached to a newly created context
-
Olivier Crête authored
-
Philip Withnall authored
Previously, there was a race between receiving the data packets and changing state to READY, which would cause one of the final assertions to fail.
-
Philip Withnall authored
Add one new public function, nice_agent_send_messages_nonblocking(), which replaces nice_agent_send_full(). This isn’t an API break, because nice_agent_send_full() hasn’t been in a release yet. The new API allows sending multiple messages in a single call, and supports vectors of buffers to transmit the messages from. The existing nice_agent_send() API has been left untouched, although it’s a bit of a bugbear because it’s non-blocking and doesn’t fit with the new *_nonblocking() naming scheme. Oh well. This doesn’t bring any notable changes to the number of memcpy()s on the critical path: it remains at zero for the common cases and common socket types. It introduces the possibility for future work to eliminate some memcpy()s in more complex socket types, like tcp-turn and tcp-bsd, but these optimisations have not been made yet. FIXME comments have been added. This includes modifications to the test-send-recv unit test to cover the new API.
-
Philip Withnall authored
Replace the send() API with a send_messages() API, which supports sending multiple messages, each with multiple buffers rather than a single monolithic buffer. This doesn’t break API, as the socket API is not exposed outside libnice. It does introduce a new struct: NiceOutputMessage, which is analogous to struct mmsghdr and NiceInputMessage. This includes updates to the test-bsd test to cover the changed API. The existing nice_socket_send() API has been retained as a thin wrapper around nice_socket_send_messages(), for convenience only. It’s hoped that internal usage of this API will decline to the point where it can be removed.
-
Philip Withnall authored
I completely disagree with this, and believe the C file is a much better place for them, as then they’re: • easier to read while hacking on the functions, and • easier to modify once finished hacking on the functions. I think the argument for putting them in the header files (so that the documentation is available by the function declarations) is weak, as the generated gtk-doc manual should be installed on the system alongside the header files in any case.
-
Philip Withnall authored
-
Philip Withnall authored
Add two new public functions: • nice_agent_recv_messages() • nice_agent_recv_messages_nonblocking() which allow receiving multiple messages in a single call, and support vectors of buffers to receive the messages into. The existing nice_agent_recv[_nonblocking]() APIs have been left untouched. This tidies up a lot of the message handling code internally, and eliminates a couple of memcpy()s. There are still a few more memcpy()s on the critical path, which could be eliminated with further work. In the reliable agent case, every message is memcpy()ed twice: once into the pseudo-TCP receive buffer, and once out of it. The copy on input could be eliminated (in the case of in-order delivery of packets) by receiving directly into the receive buffer. The copy on output can’t be eliminated except in the I/O callback case (when nice_agent_attach_recv() has been used), in which case the callback could be invoked with a pointer directly into the pseudo-TCP receive buffer. In the non-reliable agent case, zero memcpy()s are used. A couple of the more complex socket implementations (TURN and HTTP) have slow paths during setup, and partially also during normal use. These could be optimised further, and FIXME comments have been added.
-
Philip Withnall authored
The write() function already exists; we can’t re-define it as a callback.
-
Philip Withnall authored
stun_message_validate_buffer_length() is already fast, but requires the entire message to be in a single monolithic buffer. For introducing vectored I/O, this becomes impossible to guarantee. Rather than rewriting the STUN code to natively support vectors of buffers (which would be a huge undertaking, and would probably slow the code down considerably), implement a fast check of whether a message is likely to be a STUN packet which *does* support vectored I/O. This can then be used to determine whether to compact the vector of buffers to a single monolithic one in order to validate the message more thoroughly.
-
Philip Withnall authored
gsize and guint8 are more obviously for binary data than gint and gchar. Note the signedness of the return type has changed: the function never returns negative values.
-
Philip Withnall authored
Replace the recv() API with a recv_messages() API, which supports receiving multiple messages, each with multiple buffers rather than a single monolithic buffer. This doesn’t break API, as the socket API is not exposed outside libnice. It does introduce a new struct: NiceInputMessage, which is analogous to struct mmsghdr. This includes updates to the test-bsd test to cover the changed API.
-
Philip Withnall authored
This introduces no functional changes.
-
Philip Withnall authored
Rather than using an intermediate method which takes a vector of buffers, just use the SHA1 iteration functions directly in the HMAC calculations. This eliminates several cases where the vector of buffers was of fixed length, and it was actually taking more code to set up and pass the vector than it would have to call the iteration functions directly.
-
Olivier Crête authored
-
Olivier Crête authored
-
Olivier Crête authored
Make sure that if the timeout is now, no negative number is passed as an unsigned
-
Olivier Crête authored
Integer comparisons need to take care of rollovers
-
Olivier Crête authored
-