Streaming over http

[Robert M. Gary]

I'm attempting to web enable one of my java applications (for a variety
of reasons, including the https security).

In one case, my client expect to connect to the server long term and
just receive async information as it happens. That doesn't seem to fit
the http model. but I know its been done. Do you just do an HTTP_GET,
then hang, then reissue a new HTTP_GET after each piece of data?
DOesn't that cause a lot of disconnect/reconnects?

-Robert

 

[Thomas Weidenfeller]

I'm attempting to web enable one of my java applications (for a variety
of reasons, including the https security).

In one case, my client expect to connect to the server long term and
just receive async information as it happens.

What happens?

That doesn't seem to fit
the http model. but I know its been done. Do you just do an HTTP_GET,
then hang, then reissue a new HTTP_GET after each piece of data?

Now you are mixing the directions. Does the server send notifications,
or does the client send requests?

DOesn't that cause a lot of disconnect/reconnects?

HTTP is probably not the best protocol for a notification service. It is
a request/response protocol. So let's assume you mean requests with long
periods of inactivity between them.

Protocol-wise you can keep the connection if you use an HTTP
implementation which can do persistent connections. Even in HTTP 1.1
persistent connections are optional, although they are highly
recommended, and typically they are implemented.

But that alone doesn't help. You need to keep the connection alive to
avoid timeouts.

However, if you requests are indeed sporadic, I don't see the need to
keep the connection alive. Why have a connection hanging around and
using some resources if you just once in a while use it?

I really can't remember which HTTP version the standard library does,
and if it does persistent connections. You have to investigate that for
a start.

/Thomas

 

[Robert M. Gary]

Are there no examples of http streaming with Java? Is see a lot of
products that advertise streaming video over http. How did those
programmer implement their algorithms in http's traditional
request,response,disconnect structure?

-Robert

 

[Oliver Wong]

Are there no examples of http streaming with Java? Is see a lot of
products that advertise streaming video over http. How did those
programmer implement their algorithms in http's traditional
request,response,disconnect structure?

I believe this is usually done with two (or more) threads, like a
solution for the producer-consumer problem. A producer connects to a server
via HTTP, makes a request, and starts copying the response into a buffer.
When the consumer feels that enough data has been buffered to ensure smooth
playback, the consumer starts consuming the buffer, and rendering it on
screen.

- Oliver

 

[Roedy Green]

Are there no examples of http streaming with Java? Is see a lot of
products that advertise streaming video over http. How did those
programmer implement their algorithms in http's traditional
request,response,disconnect structure?

Streaming is best done with UDP so you just discard packets that don't
arrive in time and do the best you can. So you are not using HTTP.

To do it with HTTP you could just ask for a giant file, and start
sending it. HTTP does not necessarily tell you how big the file is to
start. The receiver buffers up x seconds before starting the video,
and if it ever outruns the buffer, it just stops and lets the buffer
fill again, so on a slow line in lurches along, put plays full speed
when it can.

 

[Thomas Weidenfeller]

Are there no examples of http streaming with Java? Is see a lot of
products that advertise streaming video over http. How did those
programmer implement their algorithms in http's traditional
request,response,disconnect structure?

Streaming over HTTP is done in may different ways. Often the streaming
in the end is not done via HTTP, but just initiated via HTTP. E.g.:

- The server just sends an "endless" file in its response, with a
corresponding media mime type.

- The server sends back some proprietary data with a MIME type which is
actually associated with some other application. The browser hands the
data over to that other application, e.g. some media player. That other
application interprets the data as some information on how to access a
stream, and does so.

- The server sends back some standardized contend description, e.g.
SMIL. The browser hands the data over to some application which can deal
with it.

- The server sends back some HTML which has an embedded player object
definition. The browser starts the player with the parameters provided
in the HTML (one being the actual streaming source) and the player
accesses that source.

There are probably some more techniques.

/Thomas

 

[Haider Albassam]

I think it should be something like AJAX so try to see how does it
work.