A quick overview of a few interesting new web technologies: tornado, node.js and WebSockets. Listen and enjoy!
As always, we’d love to hear your thoughts and dreams and deepest desires.
If you want to learn more, check out these links:
- Tornado homepage
- node.js web page.
- Using Django on top of a Tornado web server.
- Ryan Dahl’s livejournal page (the webcomic seems to be gone though!)
- C10K problem – why webservers need to handle 10,000 concurrent clients and move to event-based IO.
- WebSockets JavaScript API, wire protocol, in node.js, in Tornado.
- A nice explanation of long polling and other workarounds
10 Comments
When it came to the Node.JS segment, I thought the podcast was a bit misleading. Node.JS is written in C, not Javascript. That’s one reason it’s so fast.
When you write a server, you’re writing it in JavaScript. As you pointed out, that JS is running under V8, currently the fastest JS interpreter. And, I believe, the fastest of all mainstream non-tokenized interpreters, including all Ruby and Python interpreters.
@Nosredna: Thanks for the correction. You’re right; I misspoke. node.js is a platform that allows you to write your web server entirely in javascript; that doesn’t mean it’s written in javascript.
I just went in and fixed this in the audio. You can hear the edit, but it’s better to be right than to sound good. Thanks for pointing this out!
Your podcast is really well done!
Topics, structure, length, and best of all you really seem to know what you’re talking about.
Looking forward to the future of this!
@Mike: Thanks!
If you’re doing asynchronous IO in Python and need to do more than just web, it is worth checking out Twisted. It doesn’t have quite the same scope as Tornado (no high level web framework), but is great for implementing asynchronous network code.
There have also been some effort put into porting the high level portions of Tornado over to Twisted, which can give the best of both worlds.
Nice work guys.
I started from this episode and soon will catchup with others. Keep up the great work.
Just wanted to say thanks. This episode is great and I’ll be listening to the others on my flight tomorrow!
Just came across your podcast–great stuff!
One quick correction about Web Sockets security (@-1:20).You mentioned that Web Sockets are secure because browsers enforce the “same-origin” mechanism in which connections can only be made to the site that served the page.
This is not correct.
WebSocket connections can be “cross-origin.” In fact, it is very common for Web Sockets to have to communicate to a different origin, because, fundamentally, Web Sockets defines a way for enables Web pages to communicate full-duplex with a remote host–a host on a different origin–like a chat server, or a messaging broker.
To do this securely, the Web Socket protocol uses the “origin model” to restrict which web pages can contact a WebSocket server when the Web Socket protocol is used from a Web page. This model requires servers to opt-in to allow communication to remote hosts. By default communication to a remote host should be denied and it is recommended that a white list of allowed origins is used (See also: the Cross-Origin Resource Sharing (CORS) specification).
One more small nit: Web Sockets is more than just a few weeks old! There has definitely been a lot of buzz around it after Chrome added native support, but I’d like to point out that work on this specification (first known as TCP Connection) began in the WHATWG in 2008. In fact, Kaazing’’s Websocket Gateway–which supports emulation for all browsers that don’t support Web Sockets natively–has been production for over a year.
Regards and keep up the good work.
Peter
Thanks for sharing. I just wish these were more frequent
Nice podcast!
BTW – I am working on a node.js debugger:
http://github.com/smtlaissezfaire/ndb
It’s still in alpha, but I don’t see why this couldn’t eventually be tied into chrome.