29 Jan, 2013, Idealiad wrote in the 1st comment:
Votes: 0
A comment on another forum caught my eye:

Quote
A jetty server out of the box could handle and retire more commands as individual http requests than any MUD ever dreamed of a decade ago using telnet.


The conventional wisdom for muds is, use Telnet, or if you're really modern, websockets. What do you all think of what this guy said?
29 Jan, 2013, quixadhal wrote in the 2nd comment:
Votes: 0
Neither.

Use JSON over a TCP/IP socket, so you're sending structured data instead of pre-formatted text.
29 Jan, 2013, Idealiad wrote in the 3rd comment:
Votes: 0
Well, http can use structured data too. I can see the benefits of keeping a socket open. But http is ubiquitous.

Of course, it's not an either/or. Using multiple protocols is fine. But this quote struck me as maybe the elephant in the room we've all been ignoring.
29 Jan, 2013, Tyche wrote in the 4th comment:
Votes: 0
Perhaps the author of the quote is ignoring the concurrency elephant?
29 Jan, 2013, Idealiad wrote in the 5th comment:
Votes: 0
OK, that's a good point. But don't many http servers these days use a single-threaded async design to get around that?
29 Jan, 2013, Tyche wrote in the 6th comment:
Votes: 0
Nginx and Lighthttpd spawn multiple worker threads to handle requests, while Apache spawned multiple processes.
At least that is the standard way Apache works on Linux. On Windows, Apache spawns threads.
Most web applications rely on database concurrency mechanisms to provide the proper locking (and store their
global state in the database).
Most muds were designed to process requests synchronously and leave global state in memory.
There are a couple that have attempted asynchronous command processing.
A mud written in pascal, Grendel, comes to mind. I'm not sure it ever worked correctly/consistently.
TeensyMud 2.0 did, but more as a joke, not attempting any resolution of thread racing.
30 Jan, 2013, Runter wrote in the 7th comment:
Votes: 0
Idealiad said:
A comment on another forum caught my eye:

Quote
A jetty server out of the box could handle and retire more commands as individual http requests than any MUD ever dreamed of a decade ago using telnet.


The conventional wisdom for muds is, use Telnet, or if you're really modern, websockets. What do you all think of what this guy said?


Particularly using a webserver to process commands as http requests? I think it's a miss, unless the game in question is a simple web based game with a lot of single player interactions. Like kingdom of loathing.

Although I think it might be a good idea to use some type of response model over a persistent connection and divide the logic up in a similar fashion to what a lot of web applications do with MVC.
23 Feb, 2013, Sazzer wrote in the 8th comment:
Votes: 0
HTTP has the big problem that it's Request/Response. The entire protocol is designed around the client sending a request and the server sending a response, and that's the end of it. In a MUD where the server might want to send messages to the client that are not a direct response to the client sending a command, this just doesn't work. There are workarounds that people have come up with - Comet, Long Polling, etc - but these are workarounds for something that is better solved in the Web world using WebSockets.
24 Feb, 2013, salindor wrote in the 9th comment:
Votes: 0
I was shown this thread by a friend who knew I am writting an html based mud. Like all great programmers I even went and reinvented the wheel and wrote my own webserver from scratch to handle my mud believing some of the other comments posted above. After I got the webserver written I finally figured out how todo with a normal webserver but was happy with my creation so there :p


So first things first, as Sazzer mentioned HTML is a query/response protocol. Muds work on a publish/subscribe model. So the first thing one has todo is create a webapp which coverts the query/response nature of the web into a publish-subscribe model. There are several paid for packages that can help with this some free, some not. But effectively you can do this with two pieces of data. A data structure of outgoing messages (don't forget about a timeout) and a token passed from the client to get the outgoing messages. The client then simply queries for these messages whenever it gets a message.

I recommend avoiding websockets as they are too new and haven't been fully ratified yet. I believe only chrome fully supports them (I think they are the ones pushing for them tobe included into the standard). ServerSideEvents are better supported (firefox and chrome I believe) but still their documentation is poor and they also haven't been fully ratified yet. Personally I don't like their setup. So this leaves long polling as the best and most compatiable method between all web browswers. Performance wise, my tests haven't noticed any response delays due to the polling method. Though I have noticed a memory leak in all browsers if you send large amounts of data over the course of multiple days without shutting it down.

Finally there comes the actual data being transmitted between the client and the server. Personally I recommned using json for dynamic data because javascript sees it as a native type and html for static data.

Hope that helps.
26 Feb, 2013, Runter wrote in the 10th comment:
Votes: 0
Quote
I recommend avoiding websockets as they are too new and haven't been fully ratified yet. I believe only chrome fully supports them (I think they are the ones pushing for them tobe included into the standard).


This is inaccurate. They're well supported (For years now) on almost every major client. They are easy to fallback to flash implementations, supported on even old versions of said clients who have flash installed, and fairly easy to fall back to older technologies also mentioned in this thread. 100% disagree that you shouldn't use websockets yet. You just need a sane fallback strategy and modern libraries for websocket support give it to you for free.
26 Feb, 2013, Rarva.Riendf wrote in the 11th comment:
Votes: 0
When you want to create a game, think about your target players.
If you want to make a game in a brownser, every gamer playing in a brownser will have websocket supported. If not…I think you can do without that perticular lost soul.
28 Feb, 2013, salindor wrote in the 12th comment:
Votes: 0
Runter said:
This is inaccurate. They're well supported (For years now) on almost every major client. They are easy to fallback to flash implementations, supported on even old versions of said clients who have flash installed, and fairly easy to fall back to older technologies also mentioned in this thread. 100% disagree that you shouldn't use websockets yet. You just need a sane fallback strategy and modern libraries for websocket support give it to you for free.


I apologize, I must have used some poor search codes when I was first looking them up as all I found were half ratified rfc's but not a ratified edition. Doing a quick search I have to agree, I would go websockets now as well…

Sorry for the bad information.

Salindor
0.0/12