Hi Friesen
Your code is yes. Please try following.
<input type="text" id="test" value="hello!">
<button onclick="ws.send(document.getElementById('test').value)">send</
button>
<script>
var ws = new WebSocket("ws://bloga.jp:80/echo");
ws.onmessage = function(msg) {
alert(msg.data)
};
</script>
You send 'hi!', You'll receive 'hi!'
If You send 'Goodbye', then see TCP Packet, You'll receive
Connection: close
eg.
GET /echo HTTP/1.1･･Upgrade: WebSocket･･Connection: Upgrade･･Host:
bloga.jp･･Origin: file://･･････
tcp 202.215.119.36:80 > 192.168.1.10:1032
( omit )
tcp 192.168.1.10:4964 > 202.215.119.36:80
･hi!････････････････････････････････････････････････････････
tcp 202.215.119.36:80 > 192.168.1.10:4964
･hi!････････････････････････････････････････････････････････
tcp 192.168.1.10:4942 > 202.215.119.36:80
･Goodbye････････････････････････････････････････････････････
tcp 202.215.119.36:80 > 192.168.1.10:4942
･Goodbye････････････････････････････････････････････････････
tcp 202.215.119.36:80 > 192.168.1.10:4942
HTTP/1.1 200 OK･･Date: Wed, 20 Jan 2010 00:16:04 GMT･･Server: Apache/
2.2.12 (Ubuntu)･･Content-Length: 0･･Connection: close･･Cont
ent-Type: text/plain････････････････････････････････････････
This "ws://bloga.jp:80/echo" is a echo server of mod_pywebsocket's
sample.
I have not checked Origin, It will work. if connected to the Internet.
Even if the local disk.
Well, There are three ways
1.Min support
2.Partial support
3.Full support
I think, case 3:
create $.websocket like $.ajax
onunload close,keep alive heatbeat,/<script(.|\s)*?\/
script>/g, "",nosupport flag etc...
now, we are looking for tips
case 2:
Some methods into the $ or $.fn
Perhaps many variations
case 1:
only create ws object
eg.
$.extend({
ws : function (url){
if(WebSocket)return new WebSocket(url);
}
})
but, This is so useless, but in the namespace.
>WS isn't HTTP
Yes, it is. Upgrade: WebSocket from HTTP GET.
eg.
tcp 192.168.1.4:1715 > 202.215.119.36:80
GET /echo HTTP/1.1･･Upgrade: WebSocket･･Connection: Upgrade･･Host:
bloga.jp･･Origin: file://････････････････････････････････････
>You do realize that WS cannot be used in most shared hosting setups?
When I started my JavaScript (1996), AddType application/x-
javascript .js even cannot be used in shared hosting. But, in a few
years, everywhere
I do not know the future, however, if it was useful, I think that
spread quickly. And perhaps there are advantages to shared hosting
sever. Because only connection for the server load low. Last week, 40
in connection load average is 0.00 at Atom CPU Server. Of course a lot
more testing is required.
Thanx
On Jan 20, 3:09 am, Daniel Friesen <nadir.seen.f...@gmail.com> wrote:
> tato wrote:
> > Thax,
>
> > First the excuses. This is a discussion about the future.
> > However, this future is in front of us.
>
> > Browser's between incompatibility in ajax was need JS Library /
> > jQuery, and was very helpful. It is, I agree.
>
> > But even if there is compatibility, jQuery support of xhr is useful.
>
> > Future browser with WebSockets implemented, I want compatibility
> > between them.
> > But I think, even if there is compatibility, jQuery support of ws is
> > useful too. Rather less code ;-)
>
> Less code?
> var ws = new WebSocket("ws://example.com");
> ws.onmessage = function(msg) {
> // ...
>
> };
>
> How much shorter can jQuery possibly make that?
>
> >> WS is a bi-directional non-HTTP socket which needs a dedicated server.
>
> > It's non-HTTP, but it's on-HTTP too.
> > I think, WS is a real bi-directional on-HTTP shares available socket,
> > isn't it?
>
> > I tested on mod_pywebsocket, that is a Web Socket extension for Apache
> > HTTP Server. IETF specification is, The Web Socket default port is 80
> > or 443.
>
> >http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-44#sectio...
> >http://code.google.com/p/pywebsocket/
> >http://blog.chromium.org/2009/12/web-sockets-now-available-in-google....
>
> WS' handshake is HTTP-like. The only "HTTP" in WS is a handshake that
> immediately upgrades the connection to the WebSocket protocol leaving
> HTTP behind.
> WS isn't HTTP, it completely breaks the request-response model of HTTP,
> it just encapsulates itself in HTTP. If WebSockets were HTTP websocket
> urls would be http:// not ws://
> The purpose of the HTTP handshake iirc is primarily so that existing
> load balancing technologies, proxy servers like varnish, etc... meant
> for http can still be used (in pipe mode ignoring contents mostly) and
> also so WS doesn't require another port which is default-blocked in most
> cases.
>
> You do realize that WS cannot be used in most shared hosting setups?
> Most shared hosts use apache, which as I recall buffers http
> requests/responses meaning WS won't work on the other side, and the
> users obviously can't install new modules. To use WS you need some sort
> of VPS, Cloud server, dedicated server, etc... Anything but a shared host.
> That there is likely a good portion of the jQuery userbase.
>
> >> WS is simply "faster" because it doesn't need all the extra cruft in a
>
> > HTTP call
>
> > I think so too. XHR requires a lot of headers, and many connections.
> > WS is Handshake header 'GET / demo HTTP/1.1 ...', only once.
>
> > WS is so friendly for network and servers. Moreover, "faster" on HTTP.
>
> > With Best regards, for into the good future
>
> > On 1月19日, 午前2:27, Daniel Friesen <nadir.seen.f...@gmail.com> wrote:
>
> >> I don't like the idea. At this point there is no reason to believe that
> >> any browser with WebSockets implemented will break spec and need a
> >> compatibility layer (the primary reason jQuery has ajax). I don't see
> >> how jQuery could add any functionality to WebSockets, the api is already
> >> quite nice, not to mention there are a large number of calls and parts
> >> to the api, so there would be a pile of jQuery code just matching up the
> >> api to make calls you could make without jQuery at all.
>
> >> In any case, comparing WS to XHR in terms of speed is completely
> >> pointless. XHR is a way to make a HTTP call from JS. WS is a
> >> bi-directional non-HTTP socket which needs a dedicated server. They have
> >> completely different purposes and use cases, speed is irrelevant to a
> >> comparison. WS is simply "faster" because it doesn't need all the extra
> >> cruft in a HTTP call and it's an open dedicated connection between the
> >> browser and the server that doesn't close after every message.
>
> >> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
>
> >> ...
>
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
--
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
