Re: [Gnash-dev] New network structure

[Rob Savoye]

Tomas Groth wrote:

> To solve this issue I'd like to suggest that we switch to our own network code,
> which is already in use in cygnal, though it will need to be worked on to fully
> support https and client side http and rtmp.

  The client's use of HTTP and HTTPS uses such a small subset of the 
HTTP protocol, that implementing our own wouldn't be that hard. About 
all it does is send GET requests. This was the initial design for 
networking in Gnash anyway.

  I think the decision to use libCurl was probably a good one at the 
time. Since libCurl doesn't handle the server side, I had to write 
implementations for Cygnal anyway. Enhancing that to support the client 
side shouldn't be too difficult. We can probably stall on HTTPS for a 
little while, and focus on HTTP and RTMP.

> * When downloading, a thread to download the entire file should be started.
> Since we want to be able to access the file meanwhile this should be done in
> small chunks and using mutexes. When handling real streams the thread should
> make sure X bytes is buffered at all time.

  We can probably store the list as an STL list container. Ideally we'd 
only want to lock around accessing a node in the list, as opposed to 
locking the whole list all the time. This should also let you easily 
seek among the part of a movie that's already been downloaded. We'd want 
X bytes to be user definable as to how much memory it could use.

> * We should probably use a circular buffer when handling real streams.
> * Support for callbacks are needed, since LoadVars and NetStream (and maybe
> others) needs support for something to happen (for example: start playback)
> when X bytes has been loaded.

  Which I believe is only supported when using RTMP. The client sends 
the control message to the server, which then does the right thing...

> Support for some http is already in cygnal, which will be moved to libbase

  libamf might be the better place, or move the protocol class from 
libamf to libbase as well. Both Cygnal and Gnash will be sharing this 
code, so just be careful not to add any subtle dependencies to Cygnal.

  For debugging RTMP, I use the free Red5 server, so I can packet sniff 
it without any worries. Red5 is written in Java, and only works with Sun 
Java, not GNU Java. You can also use Cygnal of course, but it's also 
being developed, so you might find yourself working on both ends of the 
protocol. (not necessarily a bad thing, btw)

        - rob -