Re: [ogpx] Transport independence (Re: Next Steps for OGPX WG Charter)

[Meadhbh Siobhan <[e-mail]>]

On Tue, Aug 4, 2009 at 7:03 PM, Mojito Sorbet<[e-mail]> wrote:
> I observe that the Shoutcast audio streaming service uses HTTP.  They
> initiate the connection with the headers and them leave it open for a
> loooong time sending data packets.  Similarly XMPP sends an XML 'document'
> that takes HOURS to send, very slowly, one stanza at a time;  in fact both
> ways at once.

i think the XMPP people would argue that it's sending event stream
updates using XML stanzas, not complete documents.

also, i think the reason people started streaming over HTTP was to get
through firewalls. i can't imagine that taking real time data, base64
encoding it and putting it on a HTTP transport was their first choice.

though a lesson might be gleaned from the fact that people had to do
these things.

> With those examples I see no problem in using HTTP(s) headers to describe
> the desired service endpoint (as Dave Crocker pointed out) and maybe
> encoding format, for a connection that stays open for a long time.  I do
> think an exchange of HTTP headers per operation would be huge overkill for
> all but bulk transfers:  textures, sounds, etc.

mmm... i would argue exactly the opposite. sending a single texture or
sound in a single HTTP exchange is... well... it's what HTTP was
designed to do, and several ISPs optimize for this use case.

also, the reason we want to use HTTP as a transport has less to do
with it's ability to get through firewalls or to make use of ISP
optimizations, and more to do with the fact that it defines messaging
semantics that are useful. if you look at the second life legacy
protocol, there were several points where we wanted the "fast"
behavior of UDP, but then realized we needed to get message
confirmation. we thus defined request/response semantics using UDP.
this was fine unless one of the request or response packets was
dropped, so we started developing per message rules on retransmitting
messages.

down this path leads insanity.

this is why we like HTTP. it has well defined request/response
semantics. this means that we don't have to redefine the concept of a
request in a custom UDP protocol. it is layered on top of TCP, so if
there's packet loss, an optimized software module in each hosts'
operating system will handle the recovery.

if those features did not exist in any existing protocol, it is likely
we would re-invent them. but, as it turns out, you do get them in HTTP
and you get a mature tool chain and you get the ability to interact
with OGP systems in a web browser.

> This meets the needs for both supra-transport addressing and wide network
> reach, without imposing unreasonable end-to-end round-trip delays blocking
> the channel.

i'm kind of at a loss to understand what "end to end round trip
delays" we're talking about.

>
> Independent services, such as messaging, asset downloading, locality
> information, might even use separate connections, to different endpoints,
> depending how capabilities are managed within a given virtual world
> administrative domain.
>
> -Mo
>
> Rob Lanphier wrote:
>>
>> On 08/01/2009 06:54 PM, Dave CROCKER wrote:
>>
>>>
>>> Joshua Bell wrote:
>>>
>>>>
>>>> 12. Clarify the charter that we're explicitly targetting HTTP as the
>>>> default transport.
>>>>
>>>> A concern was raised that reusing HTTP will lead to unnecessary and
>>>> tight coupling with that protocol's capabilities and semantics; a
>>>> suggestion was made that if we wish to state that the protocols will
>>>> be transport-neutral, the WG will investigate at least one other
>>>> transport. Should we just target HTTP, or make the effort?
>>>>
>>>
>>> If transport-independence is claimed, the claim won't really be
>>> meaningful unless at least two different transport mappings are provided.
>>>
>>
>> For the claim to be watertight, two different transport mappings would
>> need to be provided. However, it's still possible to make a meaningful
>> claim of transport-independence mainly by making sure that:
>> 1. The transport requirements (and non-requirements) are clearly specified
>> 2. Everyone remains vigilant about ensuring that transport expectations
>> are specified in the requirements
>>
>> Unless there's a great deal of interest from implementors to implement
>> some other transport, it seems silly to waste the effort specifying
>> another transport in the name of making a watertight claim of transport
>> independence.
>>
>> Rob
>>
>> _______________________________________________
>> ogpx mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ogpx
>>
>>
>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>