29 Oct, 2007, Hades_Kane wrote in the 1st comment:
Votes: 0
A while back my MUD used to be located at eotmud.org rather than .com and it used a different port. I'm curious if I bother registering eotmud.org again, would I be able to direct eotmud.org:9000 to eotmud.com:4000 when someone attempts to connect to the MUD?

I would know how to redirect web traffic, but I'd like to be able to direct the alternate domain to the primary one and redirect the port as well. Any suggestions?

On a similar note, in ROM's nanny, would I be able to have it recognize eotmud.org:9000 and apply a temporary value to the player? (for possible things such as a different greeting, different motd, etc.)

Thanks in advance for any replies.
29 Oct, 2007, Zeno wrote in the 2nd comment:
Votes: 0
Just point the domain to the same IP. That's what I do with biyg.org and biyg.net.

Not sure about different ports though…
29 Oct, 2007, David Haley wrote in the 3rd comment:
Votes: 0
For ports, you could set up port forwarding on the real target, that just has port 9000 loop to port 4000. That is possible, and I know how to do it with ssh, but you undoubtedly have no need for encryption since it's local. (Come to think of it, I'm not sure if ssh's port forwarding encrypts for local forwarding…)
29 Oct, 2007, Itansha wrote in the 4th comment:
Votes: 0
DavidHaley said:
For ports, you could set up port forwarding on the real target, that just has port 9000 loop to port 4000. That is possible, and I know how to do it with ssh, but you undoubtedly have no need for encryption since it's local. (Come to think of it, I'm not sure if ssh's port forwarding encrypts for local forwarding…)


Another alternative to SSH port forwarding is to use iptables to forward at the firewall level. This is assuming that you have root access and iptables available. I haven't done it in a long time, but something like this should work (from Troubleshooting Linux Firewalls by Michael Shinn and Scott Shinn, p.271):

/sbin/iptables -t nat -A PREROUTING -p tcp -dport 9000 -j REDIRECT -to-ports 4000
/sbin/iptables -A OUTPUT -t nat -p tcp -d $SERVER_EXTERNAL_IP –dport 80 -j REDIRECT –to 4000


The second line makes sure that connections initiated on the local machine will also be redirected, so you might not need it.
30 Oct, 2007, Hades_Kane wrote in the 5th comment:
Votes: 0
Thanks a bunch, Itansha! I've got traffic from port 9000 going toward 4000 now :)

Problem #1 solved.

Anyone have any ideas on having the MUD recognize which port they are coming in from?
30 Oct, 2007, Zeno wrote in the 6th comment:
Votes: 0
If you're being redirected to a port, then I don't think the code will be able to tell.
30 Oct, 2007, Hades_Kane wrote in the 7th comment:
Votes: 0
Zeno said:
If you're being redirected to a port, then I don't think the code will be able to tell.


That's what I figured, but I thought it would be worth an ask.
30 Oct, 2007, Guest wrote in the 8th comment:
Votes: 0
The codebase would be able to tell if you had it listening on both ports at the same time, but other than that, any sort of redirection would happen without its knowledge.
30 Oct, 2007, David Haley wrote in the 9th comment:
Votes: 0
The only way you could tell, I think, would be if the OS preserved the original connection info and you could query it. I don't know if the firewall level forwarding is just a reroute of the same packet, or if it actually modifies the packet's destination entries. The destination address fields do exist and can be queried, and normally you don't care; maybe this would be a place where you'd use them.

(But like I said, I really don't know what happens under the hood here.)
30 Oct, 2007, Itansha wrote in the 10th comment:
Votes: 0
No problem! I'm glad that it worked for you. :-)

As for part #2, it is probably not worth the effort, but you could setup another iptable rule that logs the forwarded connection information either to syslog or another program and then use that information to infer which user connected via the port forward. Daemon Shield makes use of the former technique and ulogd is project dedicated to the latter. While I've used daemon shield before, I'm not familiar with coding around either method.

In theory, you would create the same criteria that you did previously, but instead of using the "-j REDIRECT" rule, you would use the "-j LOG" rule (and probably add a prefix for the log: "–log-prefix='Forwarded:'") and then have a process or thread checking the syslog for lines that match. You would probably only want to log the first packet, so you'd also probably want to add "-m state –state NEW" to the criteria for the log.
30 Oct, 2007, Itansha wrote in the 11th comment:
Votes: 0
DavidHaley said:
The only way you could tell, I think, would be if the OS preserved the original connection info and you could query it. I don't know if the firewall level forwarding is just a reroute of the same packet, or if it actually modifies the packet's destination entries. The destination address fields do exist and can be queried, and normally you don't care; maybe this would be a place where you'd use them.

(But like I said, I really don't know what happens under the hood here.)


I'm not exactly sure either, since I've never actually checked the packets, but from what I read here:

Quote
The REDIRECT target is used to redirect packets and streams to the machine itself. This means that we could for example REDIRECT all packets destined for the HTTP ports to an HTTP proxy like squid, on our own host. Locally generated packets are mapped to the 127.0.0.1 address. In other words, this rewrites the destination address to our own host for packets that are forwarded, or something alike. The REDIRECT target is extremely good to use when we want, for example, transparent proxying, where the LAN hosts do not know about the proxy at all.


It sounds like the actual destination field is rewritten and that the recipient host(s) do not know that it was ever forwarded.
30 Oct, 2007, David Haley wrote in the 12th comment:
Votes: 0
It certainly does sound that way. :smile: Thanks for posting that, it clears things up.
30 Oct, 2007, Hades_Kane wrote in the 13th comment:
Votes: 0
This is a similar thought, but something I've wondered about anyway…

If two MUDs are running on the same server and would otherwise be completely compatible with one another, would there be anything that could possibly transfer a player's connection from one MUD to another? I'm sure that, by far, I'm not the only one to have ever considered having players able to travel between MUDs. Anyone ever accomplish this? It would be a solution to what I'm trying to accomplish that could possibly have greater use down the line.
30 Oct, 2007, David Haley wrote in the 14th comment:
Votes: 0
Sure, you could definitely do that. It wouldn't even be that hard, if the MUDs are truly identical. You'd need a way to have one MUD give a descriptor to the other, so that it could start reading/writing from/to it, and a way to pass a pfile across.
30 Oct, 2007, KaVir wrote in the 15th comment:
Votes: 0
Hades_Kane said:
If two MUDs are running on the same server and would otherwise be completely compatible with one another, would there be anything that could possibly transfer a player's connection from one MUD to another?


No, not unless the player is using a special client. You could redirect them to another mud from within the first, but they'd still be connecting through that first mud, giving rise to potential speed and stability issues.

I once toyed with doing something similar to what you describe. One solution I considered was to have a proxy server that all players connect through, which then redirects them to the real mud - if the proxy server is running on the same machine as the muds, it shouldn't have much of an impact on the connection speed, and because the proxy server would be very small you could take great pains to make it very robust.

The other solution I considered was to have a single mud bound to several ports, with each port appearing to connect to a different game. That's sort of cheating though.
31 Oct, 2007, David Haley wrote in the 16th comment:
Votes: 0
Actually, you can share descriptors across processes, so, no, the player does not need a special client, nor do you need to redirect traffic from one MUD to the other. (But why that would cause speed issues when everything is on the same server is unclear to me. Stability would be no more of an issue than it would already be for your networking code.) Anyhow, you need to do some tricks to get the descriptors moved around but it is possible without doing anything at all one the client end.
31 Oct, 2007, KaVir wrote in the 17th comment:
Votes: 0
My mistake - for some reason I read 'server' as 'server application' (i.e., two muds which use the same codebase, but not necessarily on the same machine). I blame it on a late night, and some recent fiddling with the Server module of my codebase.

As I noted in my second paragraph, the connection speed isn't really an issue if you're running both muds on the same machine. If both muds also share certain access rights, then you could avoid the need for a proxy server (and this time I really do mean 'server application') entirely.
31 Oct, 2007, Hades_Kane wrote in the 18th comment:
Votes: 0
I appreciate all of the responses, and it is certainly encouraging.

Hopefully I'll be able to figure it out :p
31 Oct, 2007, Keberus wrote in the 19th comment:
Votes: 0
Quote
Anyhow, you need to do some tricks to get the descriptors moved around but it is possible without doing anything at all one the client end.

Can you think of anything more specific, as I too have been interested in this for quite some time. I was also wondering if you would have to keep the connection alive on the first game if the descriptor is passed to the second, stuff like that. So anymore info would be helpful.

Thanks,
KeB
31 Oct, 2007, David Haley wrote in the 20th comment:
Votes: 0
You want to look at fcntl, dup, dup2 and related. dup2, IIRC, closes the original and lets you manipulate the copy. To be honest I haven't done this for a while so I don't remember the details. But basically you just need to pass the descriptor numbers from one process to another.

It might be easier, however, to do this using some kind of proxy that sits in front of the two servers. Less delving with OS internals, at least. You'd need to be comfortable with networking, though…
0.0/21