Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

some thoughts on bring HTTP upon UDP: iWebPP - instant web p2p technology

21 views
Skip to first unread message

tom

unread,
Mar 15, 2012, 10:07:41 PM3/15/12
to dev-w...@lists.mozilla.org
iWebPP intends to create P2P style Web techs between Web browsers.

AFAIK, dev-webapi does define how to export device service in Web Browser,
then combine iWebPP with dev-webapi should delivery the interesting service
on mobile internet, Internet of Things, etc.

Any thoughts?

Best regards
Tom


---------- Forwarded message ----------
From: tom <zs68...@gmail.com>
Date: Wed, Mar 14, 2012 at 10:26 PM
Subject: Re: [whatwg] some thoughts on bring HTTP upon UDP: iWebPP -
instant web p2p technology
To: Julian Reschke <julian....@gmx.de>, ietf-h...@w3.org


The basical idea is that we are studying on a UDP based transport to carry
HTTP, instead of raw UDP. That way is easy to reuse existing HTTP power and
at same time delivery P2P traffic to implement web realtime
apps(video/voice call, etc) between Web browsers.

Any thoughts? If it's resonable, we will create RFC draft to describe
iWebPP(protocol schema as HTTPP).

Best regards
Tom



On Wed, Mar 14, 2012 at 10:03 PM, Julian Reschke <julian....@gmx.de>wrote:

> On 2012-03-14 13:10, tom wrote:
>
>> Hi,
>>
>> AFAIK, WebRTC intends to setup P2P communication between browsers, then
>> carry video/audio/text media, etc.
>>
>> Why we need WebRTC? Firstly, Web is the most popular network app,
>> secondly,
>> video/voice brings the best user experience.
>> But, the problem is that HTTP runs on TCP by now, while P2P runs on UDP
>> normally.
>>
>> Suppose both web browser and server can run HTTP upon UDP(the protocol
>> schema as HTTPP), what happens?
>> Firstly, Web app developers can program HTTPP like HTTP, secondly, P2P
>> traffic can be carried on HTTPP easily.
>>
>> Basically iWebPP consists of two parts: HTTPP-enabled web browser and web
>> server.
>>
>> Any thoughts? thanks.
>> ...
>>
>
> Well, declaring that it should use UDP alone won't make it happen. It
> obviously will work nicely for small messages that are idempotent (so they
> can be retransmitted safely), but things get complicated beyond that.
>
> There's also previous work to study; for instance Microsoft has used HTTP
> over UDP for notifications in the past.
>
> A good place to bring this up might be the HTTPbis Working Group, which
> will be looking at what HTTP/2.0 might be very soon.
>
> Best regards, Julian
>

Thinker Li

unread,
Mar 16, 2012, 6:08:51 AM3/16/12
to mozilla-d...@lists.mozilla.org
On Mar 16, 10:07 am, tom <zs68j...@gmail.com> wrote:
> ---------- Forwarded message ----------
> From: tom <zs68j...@gmail.com>
> Date: Wed, Mar 14, 2012 at 10:26 PM
> Subject: Re: [whatwg] some thoughts on bring HTTP upon UDP: iWebPP -
>
> instant web p2p technology
> To: Julian Reschke <julian.resc...@gmx.de>, ietf-http...@w3.org
>
> The basical idea is that we are studying on a UDP based transport to carry
> HTTP, instead of raw UDP. That way is easy to reuse existing HTTP power and
> at same time delivery P2P traffic to implement web realtime
> apps(video/voice call, etc) between Web browsers.
>
> Any thoughts? If it's resonable, we will create RFC draft to describe
> iWebPP(protocol schema as HTTPP).

HTTP over UDP is what UPnP goes.
It means we should also enable server side functions to do p2p, then
applications can communicate with any peer. I am very curious how to
deal with security issues?
It is also an issue for server sockets.

Thinker Li

unread,
Mar 16, 2012, 6:18:12 AM3/16/12
to mozilla-d...@lists.mozilla.org
On Mar 16, 10:07 am, tom <zs68j...@gmail.com> wrote:
> ---------- Forwarded message ----------
> From: tom <zs68j...@gmail.com>
> Date: Wed, Mar 14, 2012 at 10:26 PM
> Subject: Re: [whatwg] some thoughts on bring HTTP upon UDP: iWebPP -
>
> instant web p2p technology
> To: Julian Reschke <julian.resc...@gmx.de>, ietf-http...@w3.org
>
> The basical idea is that we are studying on a UDP based transport to carry
> HTTP, instead of raw UDP. That way is easy to reuse existing HTTP power and
> at same time delivery P2P traffic to implement web realtime
> apps(video/voice call, etc) between Web browsers.

HTTP over UDP, it is what uPnP goes.
It means we should also enable server side functions, and we can talk
to any peers and in reversed. It rises a security issue that provide
a backdoor for malicious code to talk to any peer in background. I am
very curious how to deal it.

tom

unread,
Mar 16, 2012, 11:47:09 AM3/16/12
to mozilla-d...@lists.mozilla.org
uPnP don't provide the reliable stream for HTTP traffic. But, HTTPP is
based on a reliable UDP-based transport, that's the fundamental
diffirence.
the security issue is another story, and we are working on it.

Best regards
Tom


tom

unread,
Mar 16, 2012, 12:02:58 PM3/16/12
to mozilla-d...@lists.mozilla.org
iWebpp will enable both web browser and server support HTTPP(run HTTP
over UDP-based transport). And, iWebPP server will authenticate every
HTTPP web browser client, then,
when one web browser want to talk to another browser, the procedure
MUST control by iWebPP server also.

Best regards
Tom

Thinker Li

unread,
Mar 18, 2012, 3:24:18 AM3/18/12
to mozilla.d...@googlegroups.com, mozilla-d...@lists.mozilla.org
Do you mean that iWebPP server relays all messages among peers?
If it is what IWebPP server doing, is there any reason that you don't use WebSocket? Avoid latency of hand shaking?

Thinker Li

unread,
Mar 18, 2012, 3:24:18 AM3/18/12
to mozilla-d...@lists.mozilla.org, mozilla-d...@lists.mozilla.org
On Saturday, March 17, 2012 12:02:58 AM UTC+8, tom wrote:

tom

unread,
Mar 18, 2012, 10:51:17 PM3/18/12
to mozilla-d...@lists.mozilla.org
No, iWebPP server really don't relay any data message between browser.
It will only arbitrate to setup the secure P2P session between
browser.
Once the secure session was setup between browsers, P2P traffic will
cross browsers directly.

Best regards
Tom

0 new messages