1. 31 Jan, 2014 7 commits
    • Olivier Crête's avatar
    • 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
    • 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: 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
    • Philip Withnall's avatar
      agent: Add nice_agent_recv() allowing blocking receives on sockets · 243c47ec
      Philip Withnall authored
      This is a blocking receive function, designed to be called from a worker
      thread. It cannot be used in conjunction with the existing
      nice_agent_attach_recv() API, as the blocking receive and the GSource
      would compete over access to the single copy of the data in the kernel’s
      receive buffer.
      243c47ec
    • Philip Withnall's avatar
      agent: Move GSource handling into Component · c5672702
      Philip Withnall authored
      Rather than handle GSource creation, attachment and removal in
      NiceAgent, handle it inside Component. This brings it closer to the
      networking code, and improves encapsulation of the state of each
      Component.
      c5672702
  2. 16 Feb, 2010 2 commits
  3. 04 Nov, 2009 1 commit
  4. 28 Jul, 2009 1 commit
  5. 17 Jun, 2009 1 commit
  6. 09 Jun, 2009 1 commit
  7. 02 Jun, 2009 1 commit
  8. 25 Apr, 2009 1 commit
  9. 16 Feb, 2009 1 commit
  10. 10 Dec, 2008 1 commit
  11. 08 Dec, 2008 1 commit
  12. 04 Nov, 2008 1 commit
  13. 16 Oct, 2008 1 commit
  14. 08 Oct, 2008 1 commit
  15. 07 Oct, 2008 2 commits
  16. 22 Sep, 2008 1 commit
  17. 07 Aug, 2008 1 commit
  18. 04 Aug, 2008 2 commits
  19. 20 Jun, 2008 1 commit
  20. 01 May, 2008 2 commits
  21. 26 Apr, 2008 1 commit
  22. 22 Apr, 2008 2 commits
  23. 02 Apr, 2008 1 commit
  24. 16 Nov, 2007 1 commit
  25. 15 Nov, 2007 1 commit
  26. 10 Oct, 2007 3 commits
  27. 11 Sep, 2007 1 commit