X84 Telnet Server

I got an email this weekend from Jeff Quast who writes:

I've been writing a telnet BBS in python since about 2003. It has many similarities in your MUD. Initially we had a hand-crafted simple socket telnet daemon, then later twisted, but when we decided to get rid of twisted for a pure-python solution, I discovered your miniboa source.
It has been modified quite a bit for more advanced telnet negotiations, I encourage you to take a look. You will find NAWS, TTYPE, and even NEW_ENVIRON negotiation. I plan to release x/84 to pypi within a day or so[.]

I really enjoy it when someone dusts off my brain-addled code and manages to hammer it into something useful.  You can check out his project here;

https://github.com/jquast/x84

New Development Server

I've treated myself to the sparkly-new, dedicated development server pictured above.  It's a Raspberry-PI.  I'm happy to say my http+websocket server runs really well on it.  I'm also pleased to report that the websocket code now works with Chrome, Firefox (aka Iceweasel),  and Opera.

For the Love of Coffee, Gadgets, and Python

Most geeks are familiar with the RasberryPi Project that set out to make a tiny, hackable, and amazingly capable PC for around $25.  I've been following it with great interest.

I have to say that I was really tickled when I came across the project blog for MoccaPi .  He's designing a controller to let him remotely start and stop his coffee maker via Telnet.  The coolest part for me is the use of Miniboa for the device's server.

Miniboa ... on a RasberryPi ... making coffee.  How awesome is that?

His project was voted #10 coolest use for a RasberryPi on TechRepublic.

Desktop Linux

Linux has been my primary OS for about eight years. I am very fond of it and have often made the analogy that sitting down to a Windows box feels as clumsy as having your thumbs removed.

I used Redhat, then Fedora, then Ubuntu. It really annoyed me when they hid the kernel boot messages to be more noob friendly or stylish or whatever. My Linux boxes are workstations damn it; show me the bogomips.

Then Ubuntu gets stupid. Shuttleworth decides we need windows controls on the wrong side to prepare us for ... something. So I spend a year feeling like an American driving in Britain when using Linux and a Brit driving in the US when using Windows.

And that something turns out to be Unity.

And Unity sucks.

And my escape route is gone because my beloved Gnome had become Gnome 3 aka Gnome Shell aka Hunt the Wumpus but I give it a shot for a few weeks because it has the wonderful quality of not being Unity until it strikes me, this sucks too. So I spend an entire weekend trying different distros -- then going back to Ubuntu. Then spending the next weekend forcing XFCE into dressing up as Gnome 2. Which was close but what a weird the-opposite-of-forward step to make?

Pretty-please someone fork Gnome 2 and save the Linux desktop.

Remove the "close window?" prompt from Gnome-Terminal

$ gconftool-2 --type bool --set /apps/gnome-terminal/global/confirm_window_close "false"

#get_off_my_yard

The Web Client

Last weekend I got my WebSocket server for NetBoa working again (yay).

This weekend I've been laying out the HTML5 and CSS for the browser side. At the moment it looks like this;

It seems obvious now, but it felt like an epiphany when I realized that the project only required a single HTML page. Everything from the login screen forward will be elements dynamically create via Javascript (using the excellent JQuery lib) talking the server over a WebSocket. Chrome will happily maintain an open WebSocket for days with no activity (I tested it).

In John Gardner's book, Grendel, a dragon offers up the advice 'alternatives exclude'. I'm wrestling with some UI decisions -- screen dimensions vs. info glut. In the shot above, the left panel is somewhat like the main viewer from Star Trek;

When the right is like a console;

Originally, I had three columns where the far left one containing a kind of galactic IRC. But that was just too much.

I'm still trying to decide on a messaging protocol. JSON is great for interfacing with Javascript in the browser but that's precisely where I don't need speed. Given the short life of these message packets it seems rather wasteful to include an extra library just to generate Python objects to be cast into JSON strings a picosecond later. I'm 90% sure that I'll go with text commands and an option to send snippets of HTML.

Unpacking WebSocket Frames Cont.

Using WireShark, I captured some frames between my browser and WebSocket.org's Echo Server. This gave me some data to experiment with without needing a living server.

I mentioned that the protocol in version 13 was very different. Previously, you bookended your packets with \x00 and \xFF and shoved them down the wire. RFC 6455 adopted a more formal framing that includes op codes for the frame type (string vs binary && ping vs pong), a continuation flag, and three different data structures for describing payload size. Additionally, payloads from the Client to the Server are XOR'ed with a random 32 bit mask. This mask is included in the client frame. Frames from the Server to Client are sent in the clear. Plus some reserved fields.

Yes, it does seem a touch fiddly.

Since I'll own both ends of the wire, I should be fine with a server that only uses 'final fragment' frames (no need for messages to span data packets) using text frames. Most likely JSON. I don't plan to support the previous WS drafts since browser updates are darn near seamless today.

The output of the previous code is:

Final Frame: True
Masked: True
Opcode: 1
Payload Length: 28
Payload: Rock it with HTML5 WebSocket

Final Frame: True
Masked: False
Opcode: 1
Payload Length: 28
Payload: Rock it with HTML5 WebSocket

Final Frame: True
Masked: True
Opcode: 1
Payload Length: 165
Payload: This is a very long message that is longer than 125 bytes so it will be offet with a 16 bit extended payload length and therefore payload len should be equal to 126.

Final Frame: True
Masked: False
Opcode: 1
Payload Length: 165
Payload: This is a very long message that is longer than 125 bytes so it will be offet with a 16 bit extended payload length and therefore payload len should be equal to 126.