21–30 of 60 posts
If anything, this is understating the problem that authors just aren't doing the design work to provide addressable, reusable resources to the rest of the world. They either haven't noticed or don't care that siloed javascript apps are destroying the web.
If anything, this is understating the problem that authors just aren't doing the design work to provide addressable, reusable resources to the rest of the world. They either haven't noticed or don't care that siloed javascript apps are destroying the web.
The web was never a set of "addressable, reusable resources".
Of course, this happens within a sandbox that involves initiating the connection over HTTP and tunneling the protocol through a server over port 80. But that server can be a proxy that forwards the stream to any TCP service, on any TCP port. We're back to the days when anyone could and did develop their own protocols, and many of those became standards.
I suspect that we're going to see that kind of development again: people will initially create their own protocols to use over Websockets, then they'll recognize the benefit of tunneling existing standard TCP protocols to their Javascript programs (how about an IMAP client written in Javascript?) then finally someone will develop an HTTP client in Javascript.
Earlier quoted context omitted.
The web was never a set of "addressable, reusable resources".
Would you please explain? What is the web, in your view, if not that?
I think what lots of people are missing is that Websockets doesn't compete with REST or SOAP, it competes with HTTP. Until now, programs written in Javascript could only use one internet protocol: HTTP. Websockets brings low-level TCP socket programming to Javascript, enabling the use of any TCP-level protocol. Of course, this happens within a sandbox that involves initiating the connection over HTTP and tunneling th…
Earlier quoted context omitted.
Unity has UDP sockets and yes all good games that require fast real-time action need UDP. Adobe had it partially in their latest Flash Media Server RTMFP protocol but it was very limited. RUDP or Reliable UDP is the best of both. Here's some great info on UDP vs TCP and only using one or the other: UDP vs TCP http://gafferongames.com/networking-for-game-programmers/udp... Characteristics of UDP Packet Loss: Effect of…
RUDP sounds very weird... why would you use it instead of TCP? At a glance, it looks like the only difference is RUDP doesn't enforce packets being received in-order (being a message-based protocol), while TCP does (being a stream-based protocol).
For instance let's say you have some physics update and for some reason you needed it networked, with many objects, receiving only 70% of those for many different elements may be just fine (discarding any you receive after that are older maybe for this example)...you may not need reliable acknowledgement that they received for most of them if any. But you definitely need to know when an enemy is killed so you make that a critical message to the server RPC'd to the clients and use a reliable flag which then will expect validation. Same with ordering... use when needed with RUDP or custom layer on UDP for reliability.
TCP does all this for you and works great for files/http etc. but doing this for all messages is great overkill in real-time games lower than turn based. And mixing TCP/UDP arguably causes some slowdown to UDP due to TCP queuing. RUDP solves all these issues and is flexible to reliable messages and just firehose broadcast.
http://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol Designed by none other than Bell Labs...
Also SCTP was created to solve RUDP like issues as an official standard (RUDP is a draft) but standards take time: http://en.wikipedia.org/wiki/Stream_Control_Transmission_Pro...
Earlier quoted context omitted.
Unity has UDP sockets and yes all good games that require fast real-time action need UDP. Adobe had it partially in their latest Flash Media Server RTMFP protocol but it was very limited. RUDP or Reliable UDP is the best of both. Here's some great info on UDP vs TCP and only using one or the other: UDP vs TCP http://gafferongames.com/networking-for-game-programmers/udp... Characteristics of UDP Packet Loss: Effect of…
RUDP sounds very weird... why would you use it instead of TCP? At a glance, it looks like the only difference is RUDP doesn't enforce packets being received in-order (being a message-based protocol), while TCP does (being a stream-based protocol).
So, in a nutshell, we're seeing a swing back to RPC. I think that's great, bidirectional RPC is much nicer than REST. REST is great, but a good portion of the time proper rest begins to feel like square peg round hole, that's why we see endless discussions of 'proper' rest.
bidirectional RPC is much nicer than REST. I don't see why - REST seems extremely elegant to me. In any case, they solve completely different problems. REST is a set of constraints that ensure your architecture will be scalable, reliable, efficient (by allowing multiple levels of caching), easy to evolve (by being extremely decoupled) and linkable. WebSockets throw away all that to ensure you can have low latency rea…
There will never be an enviable end-user Single Page Application built on a purely REST architecture style since REST/HATEOS promotes the idea of dumb clients driven by a single server view, in a page-by-page mode Netscape 4 would be proud of. This is great if you're building one of the turn-based games of the 90s but the REST of the world has moved - and the talented kids who can cut stellar client side apps aren't doing it with a restricted HATEOS mindset.
So while Google makes arguably the best REST client with Chrome, they're not wasting their time trying to restrict their Single Page Apps around HATEOS constraints. Instead they're investing heavily in trying to move the web forward with technologies that actually improve end-user experience like WebSockets and SPDY - rather than wasting their time chasing REST compliance badges, that's what REST cults do.
I belive that this is the future. With things such as Backbone.Sync written to communicate with websockets(via Socket.io). We can Keep Backbone models in sync easily. https://github.com/logicalparadox/backbone.iobind Fog Creek's new Trello syncs data using websockets as well. Its quite effective and works well. Trello also falls back to a regular short-polling system if it needs to.
I think what lots of people are missing is that Websockets doesn't compete with REST or SOAP, it competes with HTTP. Until now, programs written in Javascript could only use one internet protocol: HTTP. Websockets brings low-level TCP socket programming to Javascript, enabling the use of any TCP-level protocol. Of course, this happens within a sandbox that involves initiating the connection over HTTP and tunneling th…