- 08 Mar, 2019 1 commit
-
-
Jakub Adam authored
In this mode, activated by setting "ice-trickle" property of a NiceAgent to TRUE, a component without a successful connectivity check will wait indefinitely for more remote candidates to come. nice_agent_peer_candidate_gathering_done() must be called after receiving the last remote candidate for the component to finally change its state to NICE_COMPONENT_STATE_FAILED.
-
- 14 Dec, 2018 1 commit
-
-
Jakub Adam authored
The streams are matched by the order in which they appear in the SDP, not by name, so insisting on local streams to have one makes no sense. This likely should have been removed in 5972db04.
-
- 21 Jun, 2017 2 commits
-
-
Olivier Crête authored
-
Olivier Crête authored
This makes it easier to read and more extensible.
-
- 12 Jun, 2017 1 commit
-
-
Fabrice Bellet authored
This patch implements Regular Nomation as described in RFC5245 8.1.1.1. The controlling agent lets valid pairs accumulate, and decides which pair to recheck with the use-candidate attribute set. priv_mark_pair_nominated() follows 7.2.1.5, to update the nominated pair when acting as a STUN server, and priv_map_reply_to_conn_check_request() implements 7.1.3.2.4 to update the nominated pair when acting as a STUN client. A new property is also added to the agent to control the nomination mode, which can be regular of aggressive, with default value set to aggressive. Two new flags are introduced in the CandidateCheckPair structure: - use_candidate_on_next_check indicates the STUN client to add the use-candidate attribute when the pair will be checked. At this time, the nominated flag has not been set on this pair yet. - mark_nominated_on_response_arrival indicates the STUN server to nominate the pair when its succesfull response to a previous triggered check will arrive (7.2.1.5, item #2) Differential Revision: https://phabricator.freedesktop.org/D811
-
- 20 Apr, 2015 3 commits
-
-
Olivier Crête authored
Only 6 strings are valid. https://bugs.freedesktop.org/show_bug.cgi?id=90019
-
Olivier Crête authored
The include file names are very generic, at least make the guards a bit less generic. https://bugs.freedesktop.org/show_bug.cgi?id=90013
-
Ilya Konstantinov authored
Explain that either having an I/O callback or calling nice_agent_recv* is essential for ICE connection check to succeed. https://bugs.freedesktop.org/show_bug.cgi?id=89849
-
- 14 Apr, 2015 2 commits
-
-
Rohan Garg authored
Adds new API: nice_agent_set_local_credentials().
-
Rohan Garg authored
-
- 10 Mar, 2015 1 commit
-
-
Philip Withnall authored
NULL is ((gpointer) 0). nul is '\0'. Arrays can be NULL terminated. Strings can be nul terminated.
-
- 30 Oct, 2014 1 commit
-
-
Philip Withnall authored
wrt the ML thread: http://lists.freedesktop.org/archives/nice/2014-October/000981.html
-
- 09 Oct, 2014 3 commits
-
-
Youness Alaoui authored
-
Olivier Crête authored
-
Olivier Crête authored
-
- 26 Sep, 2014 1 commit
-
-
Philip Withnall authored
GIOStream and nice_agent_remove_stream() interact slightly subtly when closing down the stream. See: https://bugzilla.gnome.org/show_bug.cgi?id=735754
-
- 21 Aug, 2014 1 commit
-
-
Philip Withnall authored
Previously, an EWOULDBLOCK return value from the low-level socket calls (including PseudoTcpSocket) would be represented by a zero number of bytes (or messages) read by the agent. This conflicts with the use of zero to represent end of stream (EOS) for pseudo-TCP connections, where the sender has indicated that they are not going to send any more bytes. So, now use GError (G_IO_ERROR_WOULD_BLOCK) to represent EWOULDBLOCK, just like the GSocket functions. Zero is reserved exclusively for if: • the number of requested bytes/messages is zero; or • reliable mode is enabled and EOS is reached. This does change the documented behaviour of the NiceAgent send/recv API, but only by allowing a new behaviour (returning zero) rather than by changing an existing one, so it should be OK.
-
- 07 Jul, 2014 4 commits
-
-
Philip Withnall authored
This removes it from the introspected bindings. It is unintrospectable because it specifies a callback (@func) which persists after the nice_agent_attach_recv() call returns. This is only supported by gobject-introspection if a full closure with GDestroyNotify callback for the user is passed in too.
-
Philip Withnall authored
-
Philip Withnall authored
These make the GSLists usable from introspection.
-
Philip Withnall authored
-
- 15 May, 2014 2 commits
-
-
Youness Alaoui authored
-
Youness Alaoui authored
-
- 29 Apr, 2014 1 commit
-
-
Olivier Crête authored
-
- 25 Apr, 2014 2 commits
-
-
Guillaume Desmottes authored
-
Olivier Crête authored
-
- 23 Apr, 2014 1 commit
-
-
Guillaume Desmottes authored
Nice to make debug logs more friendly to read.
-
- 24 Feb, 2014 1 commit
-
-
Philip Withnall authored
Expand documentation for nice_agent_gather_candidates() and nice_agent_set_remote_credentials().
-
- 31 Jan, 2014 12 commits
-
-
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
-
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
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
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
-
Philip Withnall authored
-
Philip Withnall authored
This is a non-blocking variant of nice_agent_recv(), and will be used internally by the GPollableInputStream implementation. External implementations may use it as well. It reserves the right to iterate the main context, but doesn’t currently do so.
-