04 Mar, 2013, Idealiad wrote in the 1st comment:
Votes: 0
I'd like to get some resources/tutorials/examples on how to write a websocket server in this thread, and possibly even a tutorial in this thread itself.

Of course, the easy answer is "use $this-library/framework" for so many reasons, security, functionality, etcetera, but how much fun would that be? ;D

Seriously though, while I wouldchoose an existing lib if I needed websockets 'now' I'm also interested in figuring it out from the ground up.

So far here are some links:

Deploying Websocket Muds (July 4, 2012) http://www.mudbytes.net/topic-3889

WebSockets and Web Clients (Feb 12, 2012) http://www.mudbytes.net/topic-3779

http://lucumr.pocoo.org/2012/9/24/websoc...

I think some MBers here have written implementations themselves, so if anyone has example code to link to that'd be great.
04 Mar, 2013, plamzi wrote in the 2nd comment:
Votes: 0
I read your post several times, and I'm not sure exactly what you're looking for, and looking to do.

If you're the kind of person who enjoys "figuring it out from the ground up", then just pick a language and start with the RFC:

http://tools.ietf.org/html/rfc6455

If you want to take a look at an example of a websocket server written at the low level, just look for open-source projects in the language of your preference. You don't have to wait for one specifically used in a MUD server.

Even the most technical folks in this community are primarily game designers, so I'm not sure how likely it is that someone has written a websocket server "from scratch" (whatever that means in this day and age).
04 Mar, 2013, Idealiad wrote in the 3rd comment:
Votes: 0
plamzi said:
If you want to take a look at an example of a websocket server written at the low level, just look for open-source projects in the language of your preference. You don't have to wait for one specifically used in a MUD server.


I've been doing that. There are a lot of websocket links and implementations out there though. I made this thread to help in sifting through it all.
04 Mar, 2013, salindor wrote in the 4th comment:
Votes: 0
Unfortentely this is one of those things you are going to have to just suck it up and work through it for yourself. If you have a specific question on implementation, I am sure many of us would be happy to give you our opinions.

I have implemented a web server from scratch so I understand what your going through. However, I didn't implement websockets, when I was doing the research I didn't feel it was mature enough (I have since been shown I was mistaken); but now that I have an implementation I don't see a point in adding it.

A tool I found indespensable for debugging the connections was fiddler. I don't think I would have found some of my bugs without it.
05 Mar, 2013, Idealiad wrote in the 5th comment:
Votes: 0
Thanks salindor, fiddler looks good.

I also found a pretty good answer on SO that walks through some details,

http://stackoverflow.com/a/10206861/2167...
05 Mar, 2013, roguewombat wrote in the 6th comment:
Votes: 0
My current approach to build a codebase for rapid prototyping is Node.js + Socket.io. MUDs are largely event driven applications (the exception being the game clock, but even that is just typically an event that repeats every few seconds), so it's not a stretch to use JavaScript as the language. You will easily get your server up and running and have plenty of time left over to actually sort out how to actually build a useful client and come show us what you've learned. :smile:
05 Mar, 2013, Idealiad wrote in the 7th comment:
Votes: 0
I want to clarify what "from the ground up" means for me – just using the built-in socket functionality in your language of choice. It's definitely not the way to go to get something rolling fast, at least for someone at my level, but I'm enjoying the process very much. So slow is fine for now.
05 Mar, 2013, roguewombat wrote in the 8th comment:
Votes: 0
I gotcha. I can see the fun in that - basically figuring out how to upgrade HTTP GET requests into persistent web socket connections. If you're doing it in JavaScript, though, I'd pick Socket.io over implementing all of the authentication / keep-alive / fallback code myself - that ventures into Flash sockets, AJAX long-polling, etc.
05 Mar, 2013, Barm wrote in the 9th comment:
Votes: 0
I have a combination HTTP and Websocket server in Python at http://code.google.com/p/netboa/. There's a small demo with some javascript. The last time I checked it worked under Chrome, Firefox, and Opera.

And some blog posts about unpacking frames:

http://bogboa.blogspot.com/2012/02/unpac...
http://bogboa.blogspot.com/2012/02/unpac...
http://bogboa.blogspot.com/2012/02/webso...

Hope something in there is useful.
05 Mar, 2013, Barm wrote in the 10th comment:
Votes: 0
plamzi said:
Even the most technical folks in this community are primarily game designers, so I'm not sure how likely it is that someone has written a websocket server "from scratch" (whatever that means in this day and age).


*cough*
05 Mar, 2013, Idealiad wrote in the 11th comment:
Votes: 0
Thanks Barm! I have an eye on netboa (Miniboa was very helpful when I was writing a basic socket server recently) but I forgot about those blog posts.
05 Mar, 2013, Barm wrote in the 12th comment:
Votes: 0
I've been reading your posts on clojure. Way cool project.

You might notice I dropped the "chat" line from the WS handshake in the commit I did today. It was causing one of the browsers to choke.
07 Mar, 2013, salindor wrote in the 13th comment:
Votes: 0
So I am curious sense you seem to be in the know. What advantages have you seen in upgrading the sockets from long polling to websockets? Are they more responsive? Easier to track through the logs? Have you taken any measurements, or just upgrading because its cool?

Salindor
07 Mar, 2013, Barm wrote in the 14th comment:
Votes: 0
IMHO, WebSockets are game-changing.

You get an instantaneous, bi-directional connection to the most flexible and ubiquitous client ever made. In my testing, I've opened WebSockets and let them sit idle for days on end and they just work. Why try to mimic a push with polling when you can just shove your message down the wire on demand? It's a live socket with no overhead or third parties – it just doesn't get any better. The *only* caveat I can think of is the lack of support from IE and that's about to change (also, fuck IE).
07 Mar, 2013, plamzi wrote in the 15th comment:
Votes: 0
salindor said:
So I am curious sense you seem to be in the know. What advantages have you seen in upgrading the sockets from long polling to websockets? Are they more responsive? Easier to track through the logs? Have you taken any measurements, or just upgrading because its cool?

Salindor


Websockets is not cool. It's better than that. Finally, a connection to the browser that's as close to raw sockets as we're ever going to get (some security headers can't be avoided, I guess).

I use WS exclusively in my side project, an HTML5 web UI, and it performs almost on par with an installed MUD client. I'm not even falling back to Flash or Java, let alone long-polling *shudder*. IE users should download a browser if they want to browse the Internet. Luckily, IE can download browsers.

The next best generic MUD client will run on a website and use 100% WS, of that I have no doubt.
07 Mar, 2013, roguewombat wrote in the 16th comment:
Votes: 0
Out of curiosity, do you have a single MUD server that supports both TCP sockets and Web Sockets?
07 Mar, 2013, Idealiad wrote in the 17th comment:
Votes: 0
One thing I've noticed is the many choices for websocket proxies (in addition to ssl proxies, etcetera). You could probably proxy most of the 'special' protocols if you wanted to. Don't know how much complexity that would add.
08 Mar, 2013, Barm wrote in the 18th comment:
Votes: 0
roguewombat said:
Out of curiosity, do you have a single MUD server that supports both TCP sockets and Web Sockets?


Netboa has a TCP base class called Service, which is extended into HTTP and WebSocket services, so you could run any combination of the three on a single server. At one time I was keen on writing a Telnet service that used co-routines for efficient stream decoding but I never finished it.
0.0/18