1. 09 May, 2019 2 commits
  2. 08 May, 2019 1 commit
  3. 08 Mar, 2019 1 commit
    • Jakub Adam's avatar
      agent: trickle ICE mode · a6112cec
      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.
      a6112cec
  4. 14 Dec, 2018 1 commit
  5. 21 Jun, 2017 2 commits
  6. 12 Jun, 2017 1 commit
    • Fabrice Bellet's avatar
      conncheck: implement ice regular nomination method · 0636f9ad
      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
      0636f9ad
  7. 20 Apr, 2015 3 commits
  8. 14 Apr, 2015 2 commits
  9. 10 Mar, 2015 1 commit
  10. 30 Oct, 2014 1 commit
  11. 09 Oct, 2014 3 commits
  12. 26 Sep, 2014 1 commit
  13. 21 Aug, 2014 1 commit
    • Philip Withnall's avatar
      agent: Rearchitect message handling to use GErrors for EWOULDBLOCK · ee109a91
      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.
      ee109a91
  14. 07 Jul, 2014 4 commits
  15. 15 May, 2014 2 commits
  16. 29 Apr, 2014 1 commit
  17. 25 Apr, 2014 2 commits
  18. 23 Apr, 2014 1 commit
  19. 24 Feb, 2014 1 commit
  20. 31 Jan, 2014 9 commits
    • Olivier Crête's avatar
      agent: Restore the ability nice_agent_send() to send partial buffers · 919b2c46
      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.
      919b2c46
    • Olivier Crête's avatar
      agent: Replace nice_agent_build_io_stream() with nice_agent_get_io_stream() · 430e8db5
      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
      430e8db5
    • Olivier Crête's avatar
      Remove the "length" parameter from NiceOutputMessage · 4f456a46
      Olivier Crête authored
      It was used correctly only half the time anyway
      4f456a46
    • Olivier Crête's avatar
      Remove the "to" parameter from NiceOutputMessage · 5c235a86
      Olivier Crête authored
      We never send multiple messages to separate targets in practice, so
      this will simplify the code
      5c235a86
    • Philip Withnall's avatar
      agent: Add support for vectored I/O for sends · f7b15f14
      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.
      f7b15f14
    • Philip Withnall's avatar
      socket: Add vectored I/O support for sending on sockets · 515481e6
      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.
      515481e6
    • Philip Withnall's avatar
      agent: Move gtk-doc comments from agent.c to agent.h for new API · 55e53a9c
      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.
      55e53a9c
    • Philip Withnall's avatar
      agent: Add support for vectored I/O for receives · 253be348
      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.
      253be348
    • Philip Withnall's avatar
      socket: Add vectored I/O support for receiving on sockets · dfab04cd
      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.
      dfab04cd