multiple rtsp connections to same host in multi interface

Hi,

I use libcurl for http, plain sockets and rtsp. rtsp is a bit problematic because a transfer in rtsp context
consists of a series of steps which are each individual transfers to libcurl. At each
curl_multi_remove_handle() - curl_multi_add_handle() to get at the next rtsp step the link between
easy handle and connection is lost and re-established.

All is fine for a single easy_handle to a host but in case of multiple easy_handles to a single host (on same port)
these handles each match multiple connections and reuse happens in dynamic ways. This gives problems:

- some rtsp servers want a single session being dealt with over a single socket
  (disrespecting somewhat the rfc, but one example is gstreamer and for me that's problematic)

- The CSeq's emitted on a tcp connection go up dan down with wherever the session in-use is
instead of just increasing, which leads to numbering that is not according to the rfc.

- When TCP-interleaving the server sends its stream to a specific client port so the connection having
its socket bound to that port is supposed to handle that data and not another one.

The 2nd and 3rd item convince me a client, libcurl in this case, needs to maintain the same socket
for the link, instead of hopping from one to the other.

So, curl and rtsp are not a 100% match, and I get to the point I have to fix this or give up on it.
I studied the curl code a bit (finally) and I see two directions to try solve this.

- Decide on connection reuse not only on protocol, host and portnumber but also on rtsp session_id
  when the protocol in use is rtsp. This makes sure the correct socket is reused for the handle.
  I think the session_id can be set and cleared from the code in rtsp.c. But the connection matching
  Itself would be in the normal code path for a seldom used protocol.
  That aspect I don't like so much

- Prevent breaking the link between handle and connection, so avoid
  curl_multi_remove_handle()/curl_multi_add_handle() for proceeding to the next step of the rtsp transfer. I think of a function
  curl_multi_[restart_handle|resume_handle|resume_rtsp_handle] (name tbd) which requires that a handle is already added to the multi
 handle and it has completed, then it will restart that easy handle with the new options that have been set by the application in the meantime

To perform an rtsp transfer one needs: curl_mult_add_handle - curl_multi_restart_handle multiple times - curl_multi_remove_handle

 This would add a function to the multi interface, with a bit longer help page and without much obvious use
 outside rtsp. You can see it as polluting the multi interface and I can imagine others won't like that so much. But the normal
 execution path remains untouched and it works with other protocols as well, e.g. when a handle for http is done and the application (like mine :)) knows
there is a next request to same host pending it can issue curl_multi_restart_handle() as well, and avoid the administrative overhead of a
 full curl_multi_remove_handle/curl_multi_add_handle

Aiming for a solution with highest chance of being accepted as a patch, does one of these look good enough for general use?

Thanks for any input. I don't know libcurl on the inside too well. If you see a better way please tell me!

Erik

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2019-11-05