Skip to content
  1. Jan 10, 2019
    • Daniel Stenberg's avatar
      multi: multiplexing improvements · 4c35574b
      Daniel Stenberg authored
      Fixes #3436
      Closes #3448
      
       Problem 1
      
      After LOTS of scratching my head, I eventually realized that even when doing
      10 uploads in parallel, sometimes the socket callback to the application that
      tells it what to wait for on the socket, looked like it would reflect the
      status of just the single transfer that just changed state.
      
      Digging into the code revealed that this was indeed the truth. When multiple
      transfers are using the same connection, the application did not correctly get
      the *combined* flags for all transfers which then could make it switch to READ
      (only) when in fact most transfers wanted to get told when the socket was
      WRITEABLE.
      
       Problem 1b
      
      A separate but related regression had also been introduced by me when I
      cleared connection/transfer association better a while ago, as now the logic
      couldn't find the connection and see if that was marked as used by more
      transfers and then it would also prematurely remove the socket from the socket
      hash table even in times other transfers were still using it!
      
       Fix 1
      
      Make sure that each socket stored in the socket hash has a "combined" action
      field of what to ask the application to wait for, that is potentially the ORed
      action of multiple parallel transfers. And remove that socket hash entry only
      if there are no transfers left using it.
      
       Problem 2
      
      The socket hash entry stored an association to a single transfer using that
      socket - and when curl_multi_socket_action() was called to tell libcurl about
      activities on that specific socket only that transfer was "handled".
      
      This was WRONG, as a single socket/connection can be used by numerous parallel
      transfers and not necessarily a single one.
      
       Fix 2
      
      We now store a list of handles in the socket hashtable entry and when libcurl
      is told there's traffic for a particular socket, it now iterates over all
      known transfers using that single socket.
      4c35574b
  2. Jan 09, 2019
  3. Jan 08, 2019
  4. Jan 07, 2019
  5. Jan 06, 2019
  6. Jan 04, 2019
  7. Jan 03, 2019
  8. Jan 02, 2019
  9. Jan 01, 2019
  10. Dec 31, 2018
  11. Dec 30, 2018
  12. Dec 27, 2018
    • Daniel Gustafsson's avatar
      RELEASE-NOTES: synced · a63fe3e5
      Daniel Gustafsson authored
      a63fe3e5
    • Claes Jakobsson's avatar
      hostip: support wildcard hosts · d8cae791
      Claes Jakobsson authored
      This adds support for wildcard hosts in CURLOPT_RESOLVE. These are
      try-last so any non-wildcard entry is resolved first. If specified,
      any host not matched by another CURLOPT_RESOLVE config will use this
      as fallback.
      
      Example send a.com to 10.0.0.1 and everything else to 10.0.0.2:
        curl --resolve *:443:10.0.0.2 --resolve a.com:443:10.0.0.1 \
             https://a.com https://b.com
      
      
      
      This is probably quite similar to using:
        --connect-to a.com:443:10.0.0.1:443 --connect-to :443:10.0.0.2:443
      
      Closes #3406
      Reviewed-by: default avatarDaniel Stenberg <daniel@haxx.se>
      d8cae791
  13. Dec 26, 2018
  14. Dec 25, 2018
  15. Dec 24, 2018
  16. Dec 23, 2018
  17. Dec 22, 2018