Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[wierd]

I did some quick and dirty calculations, after having some connected players complain about sluggish performance, despite the dwarves on my local terminal going warpspeed at over 100fps...


PuTTY by default limits the connection speed to 38400 bytes per second. (Roughly equal to a 33.6k modem).  I did some back of the envelope calculations...

A 25x80 viewport can only draw at maximum 18.7 fps at this rate. This means that my players are missing approximately 8 out of 10 frame updates.

In order to update the client at the full 100fps, the client has to pull data at a rate of. 205000 bytes per second.  That is 200k/sec. This is outside the bounds of a consumer highspeed connection for upload. This means that unless you pay for professional hosting, the server won't be able to push the bits down the wire fast enough. (Remember, this is per client!)

Is there any chance to update dfterm to support ssh style connections with data compression? The pure ascii nature of the datastream would lend itself very well to live feed compression, and would allow much more data to be delivered to the client for rendering than a straight uncompressed feed.

(Either that, or do something with persistence and single char updates only when a glyph changes between frames, to cull the total bandwidth used.)

Sorry for necroing the thread, but I thought I would request this feature.

[Adeon]

I did some quick and dirty calculations, after having some connected players complain about sluggish performance, despite the dwarves on my local terminal going warpspeed at over 100fps...


PuTTY by default limits the connection speed to 38400 bytes per second. (Roughly equal to a 33.6k modem).  I did some back of the envelope calculations...

A 25x80 viewport can only draw at maximum 18.7 fps at this rate. This means that my players are missing approximately 8 out of 10 frame updates.

In order to update the client at the full 100fps, the client has to pull data at a rate of. 205000 bytes per second.  That is 200k/sec. This is outside the bounds of a consumer highspeed connection for upload. This means that unless you pay for professional hosting, the server won't be able to push the bits down the wire fast enough. (Remember, this is per client!)

Is there any chance to update dfterm to support ssh style connections with data compression? The pure ascii nature of the datastream would lend itself very well to live feed compression, and would allow much more data to be delivered to the client for rendering than a straight uncompressed feed.

Technically supporting SSH is possible but I can't be arsed. It could be done for Linux/FreeBSD systems with some code and changes to the interface system in dfterm2.

(Either that, or do something with persistence and single char updates only when a glyph changes between frames, to cull the total bandwidth used.)

Sorry for necroing the thread, but I thought I would request this feature.

Dfterm2 only sends what has changed on the view to the clients so your calculations are off unless everything on screens change at every frame. Did you actually check with a traffic monitor?

Dfterm2 also throttles and discards updates in a way that doesn't cause glitches if it detects the peer isn't receiving data fast enough. This way there won't ever be a stale "buffer" that is waiting to be sent.

As you can see, this has been thought out already. I highly doubt this is a Dfterm2 problem.

Also, Dfterm2 already limits FPS to somewhere between 30-60 (depends on system) so you can't get 100 frames per second ever with current versions.

[wierd]

No, I didn't check with a wire monitor. (Is bad... )

I just know that most consumer ISPs limit the upload pipe, in favor of the download pipe. Most consumers have a hard time pushing bits faster than 20k/sec for total upload capacity. In reality, it is usually closer to 5k/sec, to 15k/sec, with throttling.

My users claim to have noticed an improvement after telling putty to connect at 115200, instead of 38400, but due to total upload speed on my end I am loath to have them connect faster than that.  Due to it being a live stream, I suppose it could be a QoS related problem.. (where the isp thinks it is ordinary dumb data that can arrive out of order\throttled, and so it gets demoted in favor of VoIP, and other high priority packets.)

I will need to do some remote site testing with wireshark (or similar) to find out.

I was just hoping for data compression, because it would help with the "tiny pipe" problem.

I suppose that since my host *is* linux, I could be brazen and tell my clients to connect using a remote ssh shell under the limited user I created for dfterm, and then have them run the "local" telnet, connect to the loopback to talk to dfterm, and use the ssh daemon to deal with all the over-the-wire traffic.

Loopback is not physically constrained for how fast it can deliver bits, so that kludge should give me the compression I want with little else going on. However, I don't know if dfterm can handle multiple connections from the "same host" like that.  (Eg, user A and user B are both using compressed ssh sessions, and appear to dfterm as being the localhost. How does dfterm know which is which?)

Testing is necessary...

I just wish american ISPs would be more friendly about people running a server, since that is how the internet was actually designed. As-is, they think running a server is "srs business!" And that consumers should only ever download.  It sucks.

[Carnes]

Wierd, i think that is a decent solution for you.  Putty can execute a command upon connecting (Connection->SSH->Remote command) like "telnet localhost:8000; exit".  You can also bypass an ssh login by distributing the account's private key with putty.  So all a user would have to do it run a .bat or open putty and open a session.  The connection would be encrypted and compressed. 

You can connect multiple times to DFTerm2 from localhost as well.

[wierd]

Hey Carnes,

Could I get you to test for me?  I can ssh to the system remotely already.

I will PM you the ssh details if you are willing to see how compression interacts with things.

[Carnes]

Yeah, np.  Moving to private PMs until we have something tangible to report.

[Adeon]

Wierd, i think that is a decent solution for you.  Putty can execute a command upon connecting (Connection->SSH->Remote command) like "telnet localhost:8000; exit".  You can also bypass an ssh login by distributing the account's private key with putty.  So all a user would have to do it run a .bat or open putty and open a session.  The connection would be encrypted and compressed. 

You can connect multiple times to DFTerm2 from localhost as well.

If you do this, make sure your telnet is safe. For example, with default parameters, the telnet on Linux lets anyone to escape to telnet command prompt with ^] which in turn lets them to access a shell. Which is probably not what is intended. There may be other safety issues there but I would not be aware of them.

[wierd]

The big one is making sure they can't change fs security, can't add execute bits on created files with chmod and chown, and can't invoke sudo.

I haven't completely hardened that user in that way yet, so no public displays of credentials.

[PhantomXD]

Hey there awesome project you got going here. I had this problem for a few days now i noticed on a server i connected to that they were using phobuses graphics pack. So me and a friend could play i decided to give it a go all is working fine but i cant for the life of me work out how to install a graphics pack for my server or find the directory of DF that the game is running from unless i have completely misunderstood. thoughts?

[Carnes]

Hey there awesome project you got going here. I had this problem for a few days now i noticed on a server i connected to that they were using phobuses graphics pack. So me and a friend could play i decided to give it a go all is working fine but i cant for the life of me work out how to install a graphics pack for my server or find the directory of DF that the game is running from unless i have completely misunderstood. thoughts?

The graphics is actually done on the client side rather than the server side.  It is just a TrueType Font of the graphics tileset.  For a good starting setup, you can download this: https://sourceforge.net/projects/dfmp/files/Windows/DFMP.zip/download
The readme will explain how to install fonts and so on.  You can change one of the built in servers to your own dfterm address.  Will your server be permanent and public?

[PhantomXD]

That's perfect thanks guys 

[FuriKuri]

This looks sick! I cant wait to try it out! But I've run into a problem...
For some reason dfterm2 wont launch any slots. I double checked the paths and everything should be fine.
I'm running dfterm2 on a Ubuntu server and i'm using DF 31.25.
Thanks in advance

[Carnes]

This looks sick! I cant wait to try it out! But I've run into a problem...
For some reason dfterm2 wont launch any slots. I double checked the paths and everything should be fine.
I'm running dfterm2 on a Ubuntu server and i'm using DF 31.25.
Thanks in advance

Anything showing up in the dfterm2.log?  You can also run DF in text mode outside of dfterm2?

[FuriKuri]

Anything showing up in the dfterm2.log?  You can also run DF in text mode outside of dfterm2?

Yes. DF works fine outside dfterm2. Do you know where log is located? I cant seem to find it.

[Kraggh]

Hi! Can I play in LAN?