04 Apr, 2011, sankoachaea wrote in the 221st comment:
Votes: 0
Sure, forgive me. Something in the previous discussion had me thinking you were considering an account system (to alleviate the multiplaying issue) as if you weren't already going to be implementing accounts. Regardless of what you do for multiplaying, accounts seem necessary. My mistake.

Multiplaying policy differs from MUD to MUD… the implications of that fact make the solution obvious to me: don't try to stop multiplaying at the client (Aspect) level.
04 Apr, 2011, Chris Bailey wrote in the 222nd comment:
Votes: 0
I would have to agree that you shouldn't worry about multiplaying at the client level, but I don't think you should need to worry about it at all. =)
04 Apr, 2011, Twisol wrote in the 223rd comment:
Votes: 0
Chris Bailey said:
I would have to agree that you shouldn't worry about multiplaying at the client level, but I don't think you should need to worry about it at all. =)

Right, but as has been noted, many MUDs rely on the IP address for tracking multiplayers, and a proxy client nullifies that information. I need to restore it.
05 Apr, 2011, Vigud wrote in the 224th comment:
Votes: 0
Twisol said:
Chris Bailey said:
I would have to agree that you shouldn't worry about multiplaying at the client level, but I don't think you should need to worry about it at all. =)

Right, but as has been noted, many MUDs rely on the IP address for tracking multiplayers, and a proxy client nullifies that information. I need to restore it.
Isn't that exactly the same problem that MUD admins had in the Dark Ages of the Internet when they used to set up tunnels to make route between some players and their MUD shorter?

I'm looking at source code of one of those tunnels. It simply reads client's host and sends it to the MUD in some fancy format. Then, I guess, the MUD was supposed to treat that string as player's address (or a part of it, the other part being "my tunnel in New Reno"), so bans were possible and the gods could see those player's addresses too. I believe such MUDs accepted that format only in case of connections from tunnels.
05 Apr, 2011, Twisol wrote in the 225th comment:
Votes: 0
I have no idea! :smile: Is that forwarding format documented anywhere that you know of, or is it even still supported today?
05 Apr, 2011, chrisd wrote in the 226th comment:
Votes: 0
Twisol said:
I have no idea! :smile: Is that forwarding format documented anywhere that you know of, or is it even still supported today?


Why not just send the user's IP using GMCP/MSDP/whatever's available? Seems a bit more flexible.
05 Apr, 2011, quixadhal wrote in the 227th comment:
Votes: 0
Or, instead of futzing about with a psuedo-standard, just use NEW-ENVIRON, which is already part of the TELNET spec? Assuming you have control over the server code that will be getting connections handed to it, you could also just have your proxy thing listen on a port (internal interface only), and reply with the correct IP address of a given socket.
05 Apr, 2011, Cratylus wrote in the 228th comment:
Votes: 0
chrisd said:
Twisol said:
I have no idea! :smile: Is that forwarding format documented anywhere that you know of, or is it even still supported today?


Why not just send the user's IP using GMCP/MSDP/whatever's available? Seems a bit more flexible.


Just make sure you use the standard.

Oh..wait…
05 Apr, 2011, Scandum wrote in the 229th comment:
Votes: 0
Cratylus said:
Just make sure you use the standard.


Mud Standards: When you're ready to step up and play with the professionals.
05 Apr, 2011, Twisol wrote in the 230th comment:
Votes: 0
quixadhal said:
Or, instead of futzing about with a psuedo-standard, just use NEW-ENVIRON, which is already part of the TELNET spec?

I just took a look. I can see how you could use this to send the IP, but I don't see much in the way of authenticating the response.

quixadhal said:
Assuming you have control over the server code that will be getting connections handed to it, you could also just have your proxy thing listen on a port (internal interface only), and reply with the correct IP address of a given socket.

I'm not sure what you mean by "the server code that will be getting connections handed to it". Do you mean Aspect or do you mean the MUD?

You did give me another idea though. If the MUD receives a connection, and it receives an IP from that connection, it could query Aspect directly to confirm. But what if more proxy clients are released (like DecafMUD)? The mechanism needs to be flexible enough to support that situation.
05 Apr, 2011, quixadhal wrote in the 231st comment:
Votes: 0
Ok, you seem to be thinking the mud will be accepting random connections from the universe at large, all of whom will be trying to spoof the IP information.

Your mud will be getting connections from one of two places. Either, a random IP address out there on the internet, in which case your IP information will be as accurate as it is anyways – or, from your proxy server, whatever that may be. If it comes from the proxy, the MUD would always see it as the same IP address, the one your proxy sits on, possibly even 127.0.0.1. In that case, your proxy needs to send the real IP information to your game by some means.

So…. YOU control the proxy. YOU control the mud server. Exactly whom are you trying to protect yourself against? If your call to getpeername() returns the address of your proxy server, you know it's not the real address, and you can use whatever information it passes to you. If getpeername() returns some other address, it must be a real connection NOT going through the proxy, so ignore any attempt to "lie" about the address.

And, unless you're getting into Scandum's game of making new standards out of thin air, don't worry about "other clients" yet. Make something that works for you, and tell others how you did it. If they like it, they'll adopt it. If they don't, maybe they'll suggest a better way… if enough people do, eventually you can formalize it into some kind of standard.
05 Apr, 2011, Twisol wrote in the 232nd comment:
Votes: 0
quixadhal said:
YOU control the mud server.

No.

I don't.
05 Apr, 2011, Vigud wrote in the 233rd comment:
Votes: 0
From a MUD admin's point of view, there would be no point in using proxy that you don't trust. If you trust it, you can assume that the addresses it gives you are correct.

From the proxy's owner point of view, I think there's no risk whatsoever, so there's no need to confirm anything.
05 Apr, 2011, Twisol wrote in the 234th comment:
Votes: 0
Vigud said:
From a MUD admin's point of view, there would be no point in using proxy that you don't trust. If you trust it, you can assume that the addresses it gives you are correct.

From the proxy's owner point of view, I think there's no risk whatsoever, so there's no need to confirm anything.

Correct. But the MUD needs to know that it's the proxy that's connecting in the first place, or it can't trust anything the connection tells it. And if it checks by IP, that locks me to using a specific IP (or a strictly defined list of them). That's extremely inflexible. Hence the need for some method of authentication.
05 Apr, 2011, Arynth wrote in the 235th comment:
Votes: 0
Just as a random thought, given I was working on a web client the other day myself. Since Aspect will be a web client, what is preventing others from using web proxies with it to spoof their IP still, even after the client can forward the IP to the mud? Having looked into website security before, the methods for accurately determining a web client's true IP are somewhat difficult, if possible at all. Some php functions used by others use a HTTP_X_FORWARDED_FOR header to try to get around proxies, but those can be spoofed too.

From the current proxying client I know of out there (that being TMC's) I don't think any of them actually forward the IP to the muds currently. How ever you decide to try to forward it, you will be the first one to do so, so I say choose something easy for people to use, otherwise most won't bother.
05 Apr, 2011, Scandum wrote in the 236th comment:
Votes: 0
Thanks for the Scandum envy, it still puts a smile on my face.

On topic. I'd advice against using NEW-ENVIRON as it requires using the NULL byte, making implementation more difficult. MSDP is fairly easy to add, and any decent mud client will support it sooner or later if KaVir continues his efforts to promote it.

The biggest drawback to the whole idea is that the server has to maintain a list of trusted proxies.
05 Apr, 2011, Twisol wrote in the 237th comment:
Votes: 0
Arynth said:
Just as a random thought, given I was working on a web client the other day myself. Since Aspect will be a web client, what is preventing others from using web proxies with it to spoof their IP still, even after the client can forward the IP to the mud?

Oh, nothing. But look at it from the PoV of a MUD admin: public open proxies are very, very bad, and there are entire lists that are kept updated with their IPs so people can ban them. It would be one thing if Aspect was just another proxy, but it's not. It's meant to be something that players should -want- to use. This means that a lot more players would be playing using a proxy, and the signal to noise ratio drops dramatically. In the case of a plain open proxy, there are so many (and there are lists of their IPs) that you can still take preventative action. By passing on the client's IP, they lose nothing.

(I should be clear that Aspect isn't an open proxy. It'll only allow connections to MUDs that deign to register with Aspect.)

Arynth said:
From the current proxying client I know of out there (that being TMC's) I don't think any of them actually forward the IP to the muds currently. How ever you decide to try to forward it, you will be the first one to do so, so I say choose something easy for people to use, otherwise most won't bother.

That's another point I really, really want to make clear: I'm not choosing. I want to find some reasonable solutions and present them to some of the MUDs I approach. I'll end up supporting whatever is best/easiest for them.
05 Apr, 2011, KaVir wrote in the 238th comment:
Votes: 0
Scandum said:
MSDP is fairly easy to add, and any decent mud client will support it sooner or later if KaVir continues his efforts to promote it.

I think I've done about as much as I can in that respect - I've released a public domain snippet and an example plugin, and I've written my experiences on a blog. Any mud owner who wants their own GUI can now create one relatively quickly.

I may write up installation instructions for a few more codebases, and put together an example Mudlet script, but for the time being I really need to get back to work on my mud.

One of the things I added to my snippet was "write once" variables - they're a type of configurable variable that can only be set if they've not yet been initialised. This allows clients to set things like CLIENT_ID and CLIENT_VERSION through MSDP if they wish, while at the same time preventing players from using scripts to wipe over valid values that have already been sent through TTYPE/MXP/etc. I wonder if Aspect could use something like that for sending a unique user ID?
05 Apr, 2011, Twisol wrote in the 239th comment:
Votes: 0
Scandum said:
The biggest drawback to the whole idea is that the server has to maintain a list of trusted proxies.

That's true. I have an idea for authenticating a connection, but it still involves managing a list. Except, rather than containing IPs, the list contains public keys. It's basically SSH's publickey authentication mechanism. Of course, that's fairly involved so I don't expect it'll be high on the list of ideas.
06 Apr, 2011, quixadhal wrote in the 240th comment:
Votes: 0
Twisol said:
Vigud said:
From a MUD admin's point of view, there would be no point in using proxy that you don't trust. If you trust it, you can assume that the addresses it gives you are correct.

From the proxy's owner point of view, I think there's no risk whatsoever, so there's no need to confirm anything.

Correct. But the MUD needs to know that it's the proxy that's connecting in the first place, or it can't trust anything the connection tells it. And if it checks by IP, that locks me to using a specific IP (or a strictly defined list of them). That's extremely inflexible. Hence the need for some method of authentication.


How many do you need? As I said, if the connection comes from your proxy, you can trust the data it wil send. If it comes from elsewhere, you ignore any data it might provide and just use getpeername()'s results. I guess I fail to see the issue that you're so worried about. Are you expecting people to just arbitrarily set up multiple proxies for the same MUD, and that the MUD admins should just accept that as somehow valid? Are the proxy servers themselves going to be run on cell phones or something, so their address will change constantly?

I set up that anyterm client on my server, just to see how well it worked. It runs on the same hardware as my game server, and so I know any connection coming from 127.0.0.1 *might* be a proxy connection. Thus, IF it passed me IP address data, I'll use it. If not, I'll report 127.0.0.1. If the connection comes from anywhere else, it is NOT a proxy (or at least, not mine), and I'll use whatever address getpeername() reports.

If I wanted to run it on a different machine, I could… and I'd change 127.0.0.1 to something else. But it's not like I'd need (or want) more than a single proxy per MUD. What would be the point?
220.0/275