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.
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).
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.
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, 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:
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.
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.
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).
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?
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).
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?
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.
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.
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.