TorilMUD Forums

Need one of these to telnet from work to play. Anyone know where I can get one?

Not sure why you need a unix shell account, but why not install some flavor (I hear Ubuntu is easier to set up than last time I tried) and run it off your home PC? If you have a static IP from your ISP your set, if not use dyndns.

Cousin is a power consumption nazi. Lemme clarify more. I just need somewhere to telnet into and then telnet out of.

Something like <a href="http://www.http-tunnel.com/html/solutions/http_tunnel/client.asp">this</a> is probably better for what you want. It lets you create a tunnel through port 80 (HTTP) than then connects to wherever you want. You won't need a relay, you'll be able to directly connect to the mud... so it'll be faster.

Just note that I'm only recommending that one because their website looked more professional than the others I looked at. I haven't used a tunneling program in years... so you might want to brows through the results of this search: http://www.google.com/search?hl=en&clie ... tnG=Search

Enjoy!

Haha yea I haven't used a tunnel since the MUD was perma laggy during the ban Europe days (cousin blocked 9999 to piss me off). Naw, Don't want to put any extra programs on my comp either :P

Now you're just being obstinant. :P

I don't know where you'd find someone giving free unix accounts to people just so you can telnet. You can either tunnel, or relay through your own computer.

Hmm I may pay for one too. Know any?

theres a bunch out there free. just google :)

I have yet to find one and my google skills aren't bad.

Did you check out http://www.red-pill.eu/freeunix.shtml already?

Use SDF. www.freeshell.org. Good bunch of folk, great service, free accounts. Make a donation if you use them lots.

-simon

OK, guess I was wrong.

Well, first time for everything I guess. ;)

Vikaz wrote:Did you check out http://www.red-pill.eu/freeunix.shtml already?

I did. Out of all of them, SDF.org actually looked like the most decent one. Anyone have an acct there and can vouch for the speed? :)

Better solution...if your cousin blocked 9999, why not just factory reset the router? Assuming you don't know his password. I've found social engineering can get you (into) a lot of places you shouldn't be...

HTTP tunneling is really inefficient if you're looking for speed because of the additional packet overhead. If his reason was to cut down on the power usage of the router, tell him his general port 80/443 traffic and mp3/mp4 downloads are FAR more because it's based on bit rate flow.

A text mud? Pfft....I've never gauged it, but I honestly don't think that it could be that intensive considering 1. you're on telnet, which means ZERO encryption and security from that protocol, and 2. it's TEXT. The ANSI color codes do add some significant size to the data packet transfers (and overall increase in bandwidth), but all in all if you take a look at log files and how long it takes to achieve a log the size of an entire Tiamat run, it's really nothing compared to what we do with onling gaming in general.

Yasden wrote:Better solution...if your cousin blocked 9999, why not just factory reset the router? Assuming you don't know his password. I've found social engineering can get you (into) a lot of places you shouldn't be...

HTTP tunneling is really inefficient if you're looking for speed because of the additional packet overhead. If his reason was to cut down on the power usage of the router, tell him his general port 80/443 traffic and mp3/mp4 downloads are FAR more because it's based on bit rate flow.

A text mud? Pfft....I've never gauged it, but I honestly don't think that it could be that intensive considering 1. you're on telnet, which means ZERO encryption and security from that protocol, and 2. it's TEXT. The ANSI color codes do add some significant size to the data packet transfers (and overall increase in bandwidth), but all in all if you take a look at log files and how long it takes to achieve a log the size of an entire Tiamat run, it's really nothing compared to what we do with onling gaming in general.

Tunneling has some overhead, but telneting through two machines has even more overhead. The data gets packaged on the server, sent to the first telnet client, unpackaged displayed and repackaged to send to the final client where it is unpackaged again.

You'd be surprised at how sensitive mudding can be also. My roomate used to run an FTP server off our cablemodem, and whenever that took over 90% of the bandwidth there would be a 2 second delay for any command I entered. It sucked ass, and caused many fights between us.

I loved paying for half of our bandwidth but never geting more than 10% of it too!

Anyway, he's being blocked from work not by his cousin. His cousin just won't let him keep his computer on so he can telnet to it...

Unfortunately, sdf.lonestar.org has some lame crap. need a metaarp account to do ssh tunneling and i can't figure out why every command i send comes with a 2nd "enter" command right after it. I can't even connect to Toril because of it lol.

Sarvis wrote:Tunneling has some overhead, but telneting through two machines has even more overhead. The data gets packaged on the server, sent to the first telnet client, unpackaged displayed and repackaged to send to the final client where it is unpackaged again.

Huh? Telnet data is raw text, unencrypted (unless you count WEP/WPA/WPA2 encryption from the router). The packet size is going to generally be the same no matter what traffic you have, but because there is so much information that plain text (and the ANSI) that can be crammed into that 1500 MTU limit, the actual packet transfers are far less. Overhead is all the additional header information you're having to tack on by going through an additional protocol (telnet/ssh to HTTP) to bypass a router's ACL.

You'd be surprised at how sensitive mudding can be also. My roomate used to run an FTP server off our cablemodem, and whenever that took over 90% of the bandwidth there would be a 2 second delay for any command I entered. It sucked ass, and caused many fights between us.

This reiterates my last statement. You're having to cram so much data through the data pipe that you were bottlenecking at the router. Unless you prioritize the protocol/static IP on your router's configs, it's just going to direct traffic as it comes....unfortunately because the number of P2P packets are going to outnumber telnet by a staggering ratio, he's going to suck up most of the bandwidth. I know this because I occasionally host an mp3 server on IRC, and I have to shut it off if I'm on the MUD in a major zone or playing my PS3 online.

Yasden wrote:Huh? Telnet data is raw text, unencrypted (unless you count WEP/WPA/WPA2 encryption from the router).

Where did I say anything about encryption?

The packet size is going to generally be the same no matter what traffic you have, but because there is so much information that plain text (and the ANSI) that can be crammed into that 1500 MTU limit, the actual packet transfers are far less. Overhead is all the additional header information you're having to tack on by going through an additional protocol (telnet/ssh to HTTP) to bypass a router's ACL.

At most you're doubling the size of the packet.

If you telnet twice, you are creating the packet and sending it twice.

However, if you telnet through a relay account you have an extra "stop" in the way. You have to receive not only that packet, but all the other packets in that data transmission, reassemble them into the result, then package them up again and send them again.

Consider it a layover, actually. You get to the airport, have to get get your stuff out of the overhead bin, get off the first plane, go to the second plane and re-present your ticket, get on and find your seat, wait to take off again and then fly to your destination.

That's relaying through a telnet client. If you tunnel, you're just showing your ticket at the security gate, then at the plane. Then when you land you're showing your ticket at the plane, then at the security counter... but there was no layover in between.

(I know you don't need to show tickets when landing, but the example needed the "tunneler" to do something right?)

Telnet and HTTP are both TCP, which means the packets are going to be reassembled no matter when they arrive. UDP is generally for things where data loss isn't critical, like a video or audio stream.

There won't be any additional overhead on the user's end created by using tunneling, because the http client handling the relay is the one having to do the packaging and repackaging. The sender and receiver just assume it's business as usual (if your company's IT guy knew you were using HTTP tunneling to get around telnet, he wouldn't be any the wiser unless he actually did packet capturing and scrutinized the contents).

You cannot double the size of a packet, because that would be called a buffer overflow. Which, as you may know, is a really big exploit and a way to gain complete control of a remote host's system via installed backdoors. The max, like I stated in my previous post, is 1500 MTU. That's including all of the header information. Most routers are pretty good at maximizing this to keep the data flow going and the overhead down. The header is going to be the same size no matter what the amount of data is.

Inherently, the vital flaw in tunneling is the relaying client's speed. If you're using a super fast relay, you wouldn't notice a difference at all really.

Yasden wrote:Telnet and HTTP are both TCP, which means the packets are going to be reassembled no matter when they arrive. UDP is generally for things where data loss isn't critical, like a video or audio stream.

If you telnet through two PCs the packets are arriving twice. Once at the the first telnet and once at the second telnet. The entire message is depackaged and reassembled.

Who the hell brought up UDP anyway?

Inherently, the vital flaw in tunneling is the relaying client's speed. If you're using a super fast relay, you wouldn't notice a difference at all really.

Exactly. You will notice a difference if you use telnet.

Really, with todays computers you can pretty much assume a fast relay.

Relay has nothing to do with the computer. It's all in the router or switch processing the information. I brought up UDP because you're referring to things being in order, which is a given because both protocols we're talking about are TCP. That's all.

You're not telnetting through two different PCs. You are using HTTP via port 80 (or 443 depending on what you're trying to do) to connect to a remote host to THEN telnet out to the destination point. You're not going to get the packets twice. The packets themselves will be sent out twice, yes, but the middle man is merely taking those packets and forwarding them on.

I really didn't want to argue the finer points of the concepts of tunneling. I was just trying to give Dartan suggestions and/or solutions. Not sure why you insist on trying to debunk everything I'm saying. :P

Somewhere we got confused. We were comparing tunneling to telnetting twice.

I was saying that telnetting through two computers is slower than tunneling, and you kept seeming to contradict that...

And I was, because it is. You're failing to understand that telnet as a protocol is just text. Telnet is just a means of connecting to a remote host that does other things you're wanting, like FTP or access to a shell account (in Dalar's case). Telnet is merely going to regurgitate anything it gets back into pure text format. I used telnet to link to one of my various linux shell accounts back in 1995 when I had to mud from a text-only Linux terminal. From there I'd log into the mud.

If you're using tunneling, you're using http because it can also telnet out. However, you're going to encounter the extra overhead that http itself generates. Tunneling is generally only used to get out either discreetly or by a company's IT staff because they have ports 21-23 blocked at the firewall. They do it because they have to, but if they had a choice without having to worry about corporate security, they'd just as soon go back to SSH/telnet/FTP because it's FAR faster and much easier to deal with if you're monitoring traffic for a specific port/protocol.

This is why telnetting to a shell account then on to the mud is far faster. The only factor that would limit the speed is that of the host of the shell account. With HTTP you have to link up to the server via port 80, then deal with any additional garbage you have going on in the background (web email, craigslist casual encounters, whatever). It's all going to slow down your relay speed because it's all being spewed at you through port 80.

I hope this clears things up for you.

Dalar, if you have any friends who use one of the many dozens of flavors of Linux or BSD, you might consider asking them if they'd set you up a shell account on their machine (providing they have a generally static IP). Don't be surprised, however, if your work has completely blocked telnet and ssh. Then you'd be forced into tunneling out. Not sure if you even got this situation worked out or not.