MudBytes
» MUDBytes Community » Coding Discussions » Protocols » [MPCP] Mud Proxy Communicatio...
Pages: << prev ... 2, 3, 4, 5, 6 next >>
[MPCP] Mud Proxy Communication Protocol, Draft for proxy communication
quixadhal
Wizard






Group: Members
Posts: 2,475
Joined: Oct 17, 2007

Go to the bottom of the page Go to the top of the page
#76 id:55787 Posted May 6, 2011, 9:52 pm

(replying to Kayle's comment about preventing certain player activity for multiple connections from the same IP)

That concept destroys community.

Lots of people use NAT firewalls at home.  Making assumptions about multiplaying based just on IP address means you are rejecting any families that might want to hop onto your MUD to play together.  Bad Idea IMHO, as that's just the kind of people you should be trying to attract.  Young kids want pew-pew shiny graphics.  The generation of folks who are most likely to play a text MUD is, in fact, the generation of people who are old enough to have families, and -- surprise surprise -- just might want to play together on the same game.

If you really want to know who each of your connections is, knowing the IP address is only a hint.  To solve the problem, you really need to uniquely identify each client, and to do that each client is going to have to support some kind of key exchange.

It's a good step to let the proxy unmask IP addresses, but it doesn't actually solve the real problem.

I would say if the MUD administrator is going to go to the effort of supporting this protocol, they could also support getting such information directly from the client -- and warning players using clients that don't support it that they are under scruity.  My ancient MUD has support for Ident (RFC1413), which used to be semi-reasonable for knowing what user was playing what character.  Even then, people playing on dialup or vt200 terminals wouldn't show up as anything but "unknown".  Nowadays, Ident is easily spoofed, and would half the time return "root" regardless.
.........................
https://lh3.googleusercontent.com/-vYoSYr4luwg/UdpJ_fYLt8I/AAAAAAAAAUw/B-8sQAoGOtA/s800/MUDBYTES_zps028f0a68.gifhttps://lh5.googleusercontent.com/-S1rE61rTCMM/UdrboSwRJsI/AAAAAAAAAYI/MVUkOP_baKs/s800/kool-aid_zpsf0068bff.png

Last edited May 6, 2011, 9:53 pm by quixadhal
Kayle
Wizard






Group: Members
Posts: 1,258
Joined: Nov 27, 2006

Go to the bottom of the page Go to the top of the page
#77 id:55798 Posted May 7, 2011, 1:28 pm

That's easily avoided though. If they're playing form the same household, there's going to be a flag I can set that allows them to get around it, but after the flag is set, there'll be a period of time where I watch to make sure they are in fact different people, and if they are actually different people I'll leave the flag alone, but if they appear to just be multiplaying I'll take the flag back off.
.........................
Owner/Coder -- Malevolent Whispers -- Development Phase - Not accepting players
Coder -- Star Wars: The Sith Wars -- Open Alpha - Players Welcome - Full System Re-writes Imminent.
FUSS Project Team Lead -- SmaugMuds.Org - The Smaug MUDs Community Center

I3 Contact: Kayle@SithWars   

http://www.elysiangamedesign.net/hq_gethinf.png                       

quixadhal
Wizard






Group: Members
Posts: 2,475
Joined: Oct 17, 2007

Go to the bottom of the page Go to the top of the page
#78 id:55800 Posted May 7, 2011, 3:50 pm

Then we're back to having a human involved in the decision.  If that's the case, I'd suggest erroring on the side of trust, since if you automatically restrict people and don't bother to review the game's actions, your family/friends/etc who are legitimately playing together from behind a NAT firewall may have already gotten frustrated and left.  The odds of them coming back are pretty slim.

If you don't impose any restrictions, but flag suspected multiplayers (IE: same IP) so that the next time you log in, you get some messages telling you to check people, it accomplishes the same thing.  The risk is, somebody might get away with something for a short time.

As for transmitting the addresses... I would definitely use a string form.  Trying to kludge something in binary is just asking for mistakes in implementation, especially in byte ordering.  In fact, it might be a rather nice service to also send along the DNS resolved address.  I have no comment on IPV6, since I don't use it on my network.
.........................
https://lh3.googleusercontent.com/-vYoSYr4luwg/UdpJ_fYLt8I/AAAAAAAAAUw/B-8sQAoGOtA/s800/MUDBYTES_zps028f0a68.gifhttps://lh5.googleusercontent.com/-S1rE61rTCMM/UdrboSwRJsI/AAAAAAAAAYI/MVUkOP_baKs/s800/kool-aid_zpsf0068bff.png

Kayle
Wizard






Group: Members
Posts: 1,258
Joined: Nov 27, 2006

Go to the bottom of the page Go to the top of the page
#79 id:55801 Posted May 7, 2011, 4:47 pm


quixadhal said:
Then we're back to having a human involved in the decision.  If that's the case, I'd suggest erroring on the side of trust, since if you automatically restrict people and don't bother to review the game's actions, your family/friends/etc who are legitimately playing together from behind a NAT firewall may have already gotten frustrated and left.  The odds of them coming back are pretty slim.


I don't really see the issue here. I'm going to be up front about there being restrictions, and have clearly documented procedures for those that are legitimately multiple people in the same household. Considering the nature of the game, they'll end up understanding why the restriction is in place by the end of the tutorial area anyway.
.........................
Owner/Coder -- Malevolent Whispers -- Development Phase - Not accepting players
Coder -- Star Wars: The Sith Wars -- Open Alpha - Players Welcome - Full System Re-writes Imminent.
FUSS Project Team Lead -- SmaugMuds.Org - The Smaug MUDs Community Center

I3 Contact: Kayle@SithWars   

http://www.elysiangamedesign.net/hq_gethinf.png                       

Twisol
Sorcerer






Group: Members
Posts: 321
Joined: Nov 30, 2009

Go to the bottom of the page Go to the top of the page
#80 id:55802 Posted May 7, 2011, 5:22 pm

quixadhal said:
As for transmitting the addresses... I would definitely use a string form.  Trying to kludge something in binary is just asking for mistakes in implementation, especially in byte ordering.

They're all string forms. The difference with the format I linked is that, unlike the default :-separated address, every address only has one representation. With the default format, you have the full, noncompact version as well as the 0-replaced and 0-removed versions.

I did a (very) small amount of research, and it looks like the standard compact form is pretty easy to get (such as with inet_ntop()). It seems like the easiest thing to do would be to match the syntax of the string returned from inet_ntop(), i.e. largest stretch of 0's replaced with :: and dotted-decimal for the last 32 bits if it's an IPv4-compatible address ("::ffff:127.0.0.1"). There's an example program in `man 3 inet_pton` you can play with.

quixadhal said:
I have no comment on IPV6, since I don't use it on my network.

You might not, but a proxy client could receive connections via IPv6 and connect to your MUD via IPv4. It still needs to give you the address somehow, whether you decide to use it or not.
.........................
http://jonathan.com/wp-content/uploads/2008/09/twisolsig.png
Cratylus@Dead_Souls_Dev: beware a man who exits the bathroom smiling

Scandum
Wizard






Group: Members
Posts: 1,948
Joined: Aug 7, 2006

Go to the bottom of the page Go to the top of the page
#81 id:58778 Posted Oct 20, 2011, 6:30 pm

I've gone ahead and added a PROXY flag to the MTTS standard, which allows proxy clients to identify themselves as proxies. I also added a Proxies subsection to the MTTS standard that details how to exchange IP address information over the NEW-ENVIRON telnet option.

The reason I picked NEW-ENVIRON is because the implementation burden is small compared to fully supporting GMCP or MSDP, and that MSDP was never intended to be used for this purpose.

http://tintin.sourceforge.net/mtts
.........................
TinTin++ Mud Client - I can't believe it's not butter!

Pages:<< prev ... 2, 3, 4, 5, 6 next >>

Valid XHTML 1.1! Valid CSS!