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
