Announcing Orbited2 Beta

[Michael Carter]

Hi everyone,

Orbited2 is a rewrite of orbited on top of eventlet; It uses websocket and Comet session protocol as its transport layer. Orbited2 offers both tcp socket and websocket proxying. So if you write a websocket server (using node, eventlet, etc.) and you want it to work with existing browsers, just deploy orbited.

Check it out: http://orbited.org/orbited2

The code base is much better structured, and far, far sleeker than the old orbited releases. I'm announcing Orbited2 as a very early Beta. Please test it out against your application and let me know how it goes. 

Its worth noting that Orbited2 is built specifically for those of you who use orbited strictly as a socket proxy. No longer is there a stomp server, or any client-side protocol libraries included. For those of you looking for a web-facing message queue, please check out hookbox.org -- it is a fine choice. If you want to keep using your existing code, you can serve irc2.js  / stomp.js, etc. from your web app and everything should work fine.

I know there are a lot of you on Orbited 0.7.x, and a couple on the yet-unreleased orbited 0.8.x.  I apologize for the fragmentation of the project, but I will be concentrating all future work on Orbited2, while Matthew Desmarais continues to support/maintain those of you still on the current orbited releases. Hopefully we can all get on board with Orbited2 soon and move forward as one.

Cheers,

Michael Carter

[Niklas B]

Hi,

I think this is a good idea, even though the transition might take
some time. I am one of the few running on 0.8 but I am not sure if
it's worth stabilizing (which is almost done) or if it's better to
focus on back porting the fixes to Orbited 0.7.x.

What do you guys think?

Also I'm interested in cleaning up the orbited.org site, which needs
to be done regardless of Orbited 2.

Regards,
Niklas

[leon]

I agree on the cleaning. As for Orbited2, I see it as an evolution of
the current Orbited - in fact, it removes MorbidQ and adds WebSocket
support (when available). Apart from that, I assume it works just like
the old one - I'll be undergoing tests with it quite soon, and then
I'll post the results of a 'dry update' (no fixes or changes in code
unless required to serve stomp.js in my case).

[tim]

So for instance I could do the following with Orbited2:

Deploy Orbited2, and use the Javascript library Orbited2.js and use
Websockets in any browser (including IE?).
Write a Tornado websocket server, which could deal with authentication
from the incoming request.
Once authenticated my Tornado setup could subscribe to a AMQP message
queue for messages for that user against a channel specified in the
original Javascript request, and if any messages are broadcast, I
simply can communicate to the browser, converting the AMQP message
into whatever format I wanted (JSON) and send it to the browser?

If that is the case, that has made my life incredibly better.

[Michael Carter]

Sounds about right. If tornado is a websocket server, then just use Orbited2.js to put a websocket in IE, etc. and you're good to go.

- Michael Carter

--
You received this message because you are subscribed to the
Orbited discussion group.
To post, send email to
   <orbite...@googlegroups.com>
To unsubscribe, send email to
   <orbited-user...@googlegroups.com>
For more options, visit
   <http://groups.google.com/group/orbited-users>

[Erik Anderson]

Trying to wrap my head around this... I think my use case is still
that of using TCPSockets, in which case WebSockets becomes an
infinitely more efficient transport protocol, but the daemon still
maintains its purpose as a transport proxy, at least when you're
dealing with a service that doesn't speak native WebSocket (or
whichever version of WebSocket your browser speaks?)

Would the js client (eventually) switch between csp and WebSocket for
TCP connections? Would orbited (eventually) accept both incoming csp
and WebSocket connections for use in proxying? Or if we try to make
use of this, are we going to need to start chaining proxies together
to convert csp to WebSocket and then into TCP ?

> >    <orbited-user...@googlegroups.com<orbited-users%2Bunsubscribe@goo glegroups.com>

[Michael Carter]

On Fri, Aug 27, 2010 at 12:17 PM, Erik Anderson <eri...@odysseus.anderson.name> wrote:

Trying to wrap my head around this... I think my use case is still
that of using TCPSockets, in which case WebSockets becomes an
infinitely more efficient transport protocol, but the daemon still
maintains its purpose as a transport proxy, at least when you're
dealing with a service that doesn't speak native WebSocket (or
whichever version of WebSocket your browser speaks?)

Orbited2 supports the same use case that Orbited supports -- a tcp proxy. Orbited2 is an architectural drop-in replacement for Orbited.

 

Would the js client (eventually) switch between csp and WebSocket for
TCP connections?  Would orbited (eventually) accept both incoming csp
and WebSocket connections for use in proxying?  Or if we try to make
use of this, are we going to need to start chaining proxies together
to convert csp to WebSocket and then into TCP ?

Orbited2 has two basic modes

1) Exposing a WebSocket api to the browser, and sending WebSocket data (with the WS protocol) to a back-end server.

2) Exposing a TCPSocket api to the browser, and sending tcp data to the back-end server.

Whichever of these two modes you chose, Orbited2 will still make the best choice of transport between Orbited2 <---> web. 

Put Otherwise:

1) When you choose a proxy protocol, (What orbited2 sends to the back-end server, i.e tcp or ws [rev75/76],) you are also choosing a browser api (TCPSocket/Websocket[rev75/76]).

2) Don't confuse the api exposed by Orbited2 (TCPSocket/WebSocket) with the transport mechanism by which Orbited2 communicates with the browser. You can be using the TCPSocket api and back-end protocol, yet Orbited2 will still speak websocket to browsers that support it, and csp to those that don't.

Does this make sense?

-Michael Carter

[Andrew Armstrong]

Hi,

I have downloaded Orbited2 and have encountered problems under IE
(like Orbited 0.7x).

I am using the simple IRC example from http://orbited.org/orbited2/intro.html
and replaced sock.send('NICK mcarter\r\n'); with a simple
alert('connected'); line.

Under Chrome and Firefox; I get 'connected'. Under IE, nothing
happens.

I traced the problem somewhere to transports.jsonp.createIframe() (no
trailing 's' in createIframe()); IE for some reason just breaks out of
the function. There is no error message or anything like that.

Are you sure orbited2 is working for IE with the TCP Socket? It does
not appear to work at all for me. I am trying to get orbited2 and
morbidq working together.

Thanks,
Andrew

[Andrew Armstrong]

Hi,

I was able to fix my issue with createIframe() by replacing the
dynamic 'i.src=javascript:var d = document; ...' script code that
created an iframe with i.src=/blank.html which seemed to fix my issue.

Not sure whether its just my end or IE9, but this seemed to work.

Regards,
Andrew

On Sep 21, 2:23 pm, Andrew Armstrong <phpla...@gmail.com> wrote:
> Hi,
>
> I have downloaded Orbited2 and have encountered problems under IE
> (like Orbited 0.7x).
>

> I am using the simple IRC example fromhttp://orbited.org/orbited2/intro.html

[Andrew Armstrong]

Hi,

I am not sure whether an error or close event is available with this
version of TCPSocket?

I tried:

Orbited2.TCPSocket.onclose = function(data) {
alert("closed2: " + data);
};
var socket = new Orbited2.TCPSocket({
orbitedUri: "(url)"
});
socket.onclose = function(data) {
alert("closed: " + data);
};

--

Unfortunately when the server side of Orbited is shutdown; no close
event is raised on the client.

Am I looking in the wrong place?

Thanks

[Niklas B]

Hi,

Most likely it's not. I haven't had the time I want to go through
Orbited2 yet, but at least in old 0.8 it won't trigger onclose, but
the HandShakeTimeOut error when it can't do it's heartbeat.

Btw, are you using Python 2.5 or 2.6?

Regards,
Niklas

[Andrew Armstrong]

Hi,

I am using Python 2.6.

Also for the Orbited/js.on developers, I have committed a simple patch
at http://github.com/Plasma/js.io/commit/a8a346d299102d21849a14eec25bc3c6ee89b193
which fixes an annoying bug where the connection under IE would not
always work for the first page load attempt (from IE6 -> IE9 beta).
Using this patch it works each time the first time.

- Andrew