headers
Howard Chu | 2 May 2010 05:04
Favicon
Gravatar

librtmp support

I started looking into adding librtmp to libcurl, but I have a few concerns 
about the library structure. E.g.

diff --git a/include/curl/curl.h b/include/curl/curl.h
index e635968..41b6ae9 100644
--- a/include/curl/curl.h
+++ b/include/curl/curl.h
 <at>  <at>  -623,6 +623,11  <at>  <at>  typedef enum {
  #define CURLPROTO_SMTP   (1<<16)
  #define CURLPROTO_SMTPS  (1<<17)
  #define CURLPROTO_RTSP   (1<<18)
+#define CURLPROTO_RTMP   (1<<19)
+#define CURLPROTO_RTMPT  (1<<20)
+#define CURLPROTO_RTMPE  (1<<21)
+#define CURLPROTO_RTMPTE (1<<22)
+#define CURLPROTO_RTMPS  (1<<23)
  #define CURLPROTO_ALL    (~0) /* enable everything */

  /* long may be 32 or 64 bits, but we should never depend on anything else
diff --git a/lib/url.c b/lib/url.c
index 56dd5dc..477af5f 100644
--- a/lib/url.c
+++ b/lib/url.c
 <at>  <at>  -137,6 +137,7  <at>  <at>  void idn_free (void *ptr); /* prototype from idn-free.h, not
  #include "http_ntlm.h"
  #include "socks.h"
  #include "rtsp.h"
+#include "curl_rtmp.h"

  #define _MPRINTF_REPLACE /* use our functions only */
(Continue reading)

Permalink | Reply | 45 comments |
headers
Daniel Stenberg | 2 May 2010 16:43
Picon
Favicon
Gravatar

Re: librtmp support

On Sat, 1 May 2010, Howard Chu wrote:

> I started looking into adding librtmp to libcurl

Whoa, that sounds awesome! Cool.

Which librtmp is this? I googled for it but it wasn't clear to me if there's 
just one or if they are many.

> I have a few concerns about the library structure. E.g.

> +#define CURLPROTO_RTMP   (1<<19)
> +#define CURLPROTO_RTMPT  (1<<20)
> +#define CURLPROTO_RTMPE  (1<<21)
> +#define CURLPROTO_RTMPTE (1<<22)
> +#define CURLPROTO_RTMPS  (1<<23)

This looks... special. What's the need for adding RTMP as five protocols?

> It strikes me that using an enum for the base protocol types would have been 
> better than using a bitmask. You're going to run out of bits very soon.

Right, as we've reached 19 in 12 years, we will reach 32 in just another 8 
years if we keep up the same pace. Can we really think of 13 addititional 
relevant protocols to add?

Besides, if you just look at the code for another 15 minutes you should soon 
find out that just using an enum is not doable without modifying how things 
work. Like CURLOPT_PROTOCOLS and CURLOPT_REDIR_PROTOCOLS and more.
(Continue reading)

Permalink | Reply | 44 comments |
headers
Daniel Stenberg | 2 May 2010 16:45
Picon
Favicon
Gravatar

Re: [PATCH] PolarSSL support in cURL

On Wed, 24 Feb 2010, Hoi-Ho Chan wrote:

>    I have patched cURL to make use of PolarSSL for all the SSL/TLS

Hi Hoi-Ho,

What happened to this work that seemed to be so good on its way?

--

-- 

  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html
Permalink | Reply | 7 comments |
headers
Howard Chu | 2 May 2010 17:14
Favicon
Gravatar

Re: librtmp support

Daniel Stenberg wrote:
> On Sat, 1 May 2010, Howard Chu wrote:
>
>> I started looking into adding librtmp to libcurl
>
> Whoa, that sounds awesome! Cool.
>
> Which librtmp is this? I googled for it but it wasn't clear to me if there's
> just one or if they are many.

http://rtmpdump.mplayerhq.hu/

>> I have a few concerns about the library structure. E.g.
>
>> +#define CURLPROTO_RTMP   (1<<19)
>> +#define CURLPROTO_RTMPT  (1<<20)
>> +#define CURLPROTO_RTMPE  (1<<21)
>> +#define CURLPROTO_RTMPTE (1<<22)
>> +#define CURLPROTO_RTMPS  (1<<23)
>
> This looks... special. What's the need for adding RTMP as five protocols?

Well, it has at least those 5 URL schemes in common use. I assumed I needed 
one per scheme. rtmp:// is the plain protocol of course. rtmpt is a special 
variant tunneled in HTTP. rtmpe is Adobe's version of encrypted rtmp (I 
hesitate to use the word "secure" since it clearly isn't...), rtmpte is rtmpe 
inside the HTTP tunnel. rtmps is rtmp inside an https tunnel. (So technically 
it ought to be "rtmpts" but Adobe just calls it rtmps.)

I'd like to try to avoid the one-shot approach used by the ldap handler, but
(Continue reading)

Permalink | Reply | 43 comments |
headers
Howard Chu | 2 May 2010 17:21
Favicon
Gravatar

Re: [PATCH] PolarSSL support in cURL

Daniel Stenberg wrote:
> On Wed, 24 Feb 2010, Hoi-Ho Chan wrote:
>
>>     I have patched cURL to make use of PolarSSL for all the SSL/TLS
>
> Hi Hoi-Ho,
>
> What happened to this work that seemed to be so good on its way?
>
Sounds interesting. I just added PolarSSL support to librtmp a couple days 
ago, so we could use it on Xbox XBMC. It would probably be nice for them to 
have this in libcurl too.

http://trac.xbmc.org/ticket/9146

--

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html
Permalink | Reply | 0 comments |
headers
Daniel Stenberg | 2 May 2010 19:38
Picon
Favicon
Gravatar

Re: librtmp support

On Sun, 2 May 2010, Howard Chu wrote:

>> This looks... special. What's the need for adding RTMP as five protocols?
>
> Well, it has at least those 5 URL schemes in common use. I assumed I needed 
> one per scheme. rtmp:// is the plain protocol of course. rtmpt is a special 
> variant tunneled in HTTP. rtmpe is Adobe's version of encrypted rtmp (I 
> hesitate to use the word "secure" since it clearly isn't...), rtmpte is 
> rtmpe inside the HTTP tunnel. rtmps is rtmp inside an https tunnel. (So 
> technically it ought to be "rtmpts" but Adobe just calls it rtmps.)

Aha, thanks for explaining. We haven't yet added anything like that so I guess 
we either do it as five protocols, or we do some new cleverer arrangement. I 
guess we can do it the easy way first as give protocol entries, at least five 
protocol handler structs, quite possibly they won't all need their own 
protocol bits. Or am I wrong?

> I'd like to try to avoid the one-shot approach used by the ldap handler, but 
> I'm not sure how to fit into the Transfer() processing. RTMP is, like LDAP, 
> a binary message-based protocol. We can't just setup the connection and then 
> let Curl_readwrite() / readwrite_data() pass the data straight from the 
> socket to Curl_client_write().

RTMP would perhaps be more like the SSH-based protocols? They're binary and 
message-based and "done right" in regards to how they are done within libcurl, 
as they are fully supported using both the easy and the multi interface etc. 
It does require a state machine so that it never blocks.

> Speaking of the ldap handler - I can't imagine that it actually gets much 
> use. Does it?
(Continue reading)

Permalink | Reply | 42 comments |
headers
Dirk Manske | 2 May 2010 20:11
Picon
Favicon

Re: No connect time with 7.20.1 and multi interface

Hi Daniel.

On Friday 30 April 2010 22:45:08 Daniel Stenberg wrote:
> On Fri, 30 Apr 2010, Dirk Manske wrote:
> > in curl 7.20.1 (and also latested version from git) we don't have a
> > connect time with the multi interface. In 7.20.0 there was a connect
> > time.
> 
> Does it never?
Yes.

> It would be great so that we can add a test case for this to go with the
> fix, to make sure we won't repeat this mistake in the future!

I've added the check to lib502.c, but that test is configured to use file
and not a network protocol, so i've copied it to lib573.c, if you
run s.t. like this
./lib573 http://curl.haxx.se/ >/dev/null
than you will find "connect time is 0" in stderr

-- lib502.c    2010-05-01 12:28:23.741310130 +0000
+++ lib573.c    2010-05-01 12:24:54.461310480 +0000
 <at>  <at>  -25,6 +25,7  <at>  <at> 
   CURLM *m = NULL;
   int res = 0;
   int running=1;
+  long connect_time = 0;
   struct timeval mp_start;
   char mp_timedout = FALSE;
(Continue reading)

Permalink | Reply | 2 comments |
headers
Howard Chu | 2 May 2010 21:22
Favicon
Gravatar

Re: librtmp support

Daniel Stenberg wrote:
> On Sun, 2 May 2010, Howard Chu wrote:
>
>>> This looks... special. What's the need for adding RTMP as five protocols?
>>
>> Well, it has at least those 5 URL schemes in common use. I assumed I needed
>> one per scheme. rtmp:// is the plain protocol of course. rtmpt is a special
>> variant tunneled in HTTP. rtmpe is Adobe's version of encrypted rtmp (I
>> hesitate to use the word "secure" since it clearly isn't...), rtmpte is
>> rtmpe inside the HTTP tunnel. rtmps is rtmp inside an https tunnel. (So
>> technically it ought to be "rtmpts" but Adobe just calls it rtmps.)
>
> Aha, thanks for explaining. We haven't yet added anything like that so I guess
> we either do it as five protocols, or we do some new cleverer arrangement. I
> guess we can do it the easy way first as give protocol entries, at least five
> protocol handler structs, quite possibly they won't all need their own
> protocol bits. Or am I wrong?

Heh, I was hoping you could tell me, I don't know what depends on these bits.

Looks like LDAP has only 1 bit, so I guess you only need multiple bits if 
libcurl itself handles all the details. If that's true, then with librtmp we 
should only need 1 bit.

[re: cleverer arrangement - change the Curl_handler.scheme to a 
NULL-terminated const char **schemes, and provide the integer index of the 
matched scheme as one of the connection parameters... I guess it's not a big 
deal either way. ffmpeg also does one structure per protocol, so I'm used to 
it by now.]
(Continue reading)

Permalink | Reply | 15 comments |
headers
Daniel Stenberg | 3 May 2010 00:28
Picon
Favicon
Gravatar

Re: librtmp support

On Sun, 2 May 2010, Howard Chu wrote:

> Heh, I was hoping you could tell me, I don't know what depends on these 
> bits. Looks like LDAP has only 1 bit, so I guess you only need multiple bits 
> if libcurl itself handles all the details. If that's true, then with librtmp 
> we should only need 1 bit.

Well, for example the bits are used when trying to find existing connections 
to re-use as then the bits must match for the connection to be considered. If 
those RTMP differences are in fact different on the wire then I think they 
might need different bits for that purpose. But ConnectionExists() *could* 
also be adjusted/customized for this particular purpose although it wouldn't 
be too pretty...

> [re: cleverer arrangement - change the Curl_handler.scheme to a 
> NULL-terminated const char **schemes, and provide the integer index of the 
> matched scheme as one of the connection parameters... I guess it's not a big 
> deal either way. ffmpeg also does one structure per protocol, so I'm used to 
> it by now.]

Right, so we can start out with the easy way for now and see if we bother 
later on to make it somewhat smarter.

>> RTMP would perhaps be more like the SSH-based protocols? They're binary and 
>> message-based and "done right" in regards to how they are done within 
>> libcurl, as they are fully supported using both the easy and the multi 
>> interface etc. It does require a state machine so that it never blocks.
>
> Hm... So you need to define a state for every step that can trigger a socket 
> I/O?
(Continue reading)

Permalink | Reply | 14 comments |
headers
Daniel Stenberg | 3 May 2010 00:29
Picon
Favicon
Gravatar

Re: No connect time with 7.20.1 and multi interface

On Sun, 2 May 2010, Dirk Manske wrote:

> I've added the check to lib502.c, but that test is configured to use file
> and not a network protocol, so i've copied it to lib573.c, if you
> run s.t. like this
> ./lib573 http://curl.haxx.se/ >/dev/null
> than you will find "connect time is 0" in stderr

Perfect! Thanks a lot. I'll turn that into a proper test case for the test 
suite, and then I'll apply your patch and make sure things are fine.

--

-- 

  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html
Permalink | Reply | 1 comment |

Gmane