[Home] [Downloads] [Search] [Help/forum]

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Suggestions
. . -> [Subject]  Keepalives.
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?
(New message)
Subject: Keepalives.
Name:
Your forum user name.
Register forum user name
Password:
Your forum password.
Forgotten password?
Message:
Message to be posted (in English, please).
Forum codes:
Check this if your message uses 'forum codes' or templates (auto-detected for new posts).
Forum codes Templates

Save this message ...

Subject review (reverse sequence)

Pages: 1 2  

Posted by Flannel   USA  (1,230 posts)  [Biography] bio
Date Mon 29 Aug 2005 10:35 PM (UTC)  [ quote  ]
Message
It's not that I don't know how it would work with a plugin, I just have no documentation about what actually happens.
Once the actual occurances are settled, it really is trivial to turn it into a plugin. Real documentation is needed, regardless of how it is implemented. So, I'll ask again, can you provide any decent documentation as to the protocol/specifications of this keep alive stuff?
~Flannel

Messiah of Rose
Eternity's Trials.

Clones are people two.
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Mon 29 Aug 2005 08:27 PM (UTC)  [ quote  ]
Message
Quote:
It's talking about setting things on TCP sockets. It's not just having people send a command or sending some text to the user, which would be layer 2, wouldn't it?
That's correct, it would be affecting layer 1. The unfortunate part is that these keepalive extensions are precisely that, non-standard extensions to the TCP/IP protocol. It's unclear to me what would happen if one side was using keepalive and the other wasn't. It's possible that simply nothing will happen, or that one side will drop the other (e.g. "You just sent this my way but it doesn't make sense to me, so go away").

Nick doesn't really have much say in the matter since he doesn't control the TCP/IP protocol. What Nick can do is turn on the (non-standard) extension, but as I said before, given past experience he is not eager to use non-standard extensions and personally I would tend to stand behind that.

Allow me to make this distinction again: the fact that we're talking to a MUD or a MUSH or a WhatTheHeck is really quite irrelevant. It doesn't matter if somebody has a background with them. If you want this to happen on the TCP/IP level, it doesn't matter what kind of program is the client and what kind is the server.

If you want to do this on the second layer - the one the client and server see - then the server needs to support such a mechanism. It's trivial to implement. It is, however, as you say, less trivial to get the change distributed to all the various game servers.

Quote:
There's no logic to the claim that it can't be done in the client if the servers--and not just the one that does it with special commands--can manage it on their own.
What's probably going on is that the server is using the non-standard extension. If the client supports the extension as well, it will issue keepalives as expected. However I hesitate to make big claims about these things until I actually see it happening and have a chance to look at it.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Neva   USA  (117 posts)  [Biography] bio
Date Mon 29 Aug 2005 07:50 PM (UTC)  [ quote  ]
Message
In which case, if you don't know how to work this with a plugin, can we leave this for Nick to look at and see if he thinks it's doable with the client or not? All this talk is very nice and all, but to be honest, he's the only one who can really make the distinction about what he can and cannot accomplish, and I know he's got at least some background with MUSHes to know what they might or might not be able to work wtih.
[Go to top] top
Posted by Flannel   USA  (1,230 posts)  [Biography] bio
Date Mon 29 Aug 2005 07:42 PM (UTC)  [ quote  ]
Message
You can't do it SOLELY on the clientside, without basically just having a trigger that sends something.
If the server doesn't support it, you'll be considered 'active', unless you find some stuff to send that doesn't make the server think you are. This is akin to making a timer, that sends (whatever), you'll have to play around with what to send per server (and you might get lucky and find something that the server doesn't reset your idle time with).

Responding to a server SO_KEEPALIVE is doable in a plugin, but honestly, I'm not sure if you need to respond at all. The NAT just needs to see some data passing and it won't disconnect.
~Flannel

Messiah of Rose
Eternity's Trials.

Clones are people two.
[Go to top] top
Posted by Neva   USA  (117 posts)  [Biography] bio
Date Mon 29 Aug 2005 07:33 PM (UTC)  [ quote  ]
Message
It's not that it's not acceptable to ask. I realize you come from a MUD background, so this is different. MUDs have coders who deal with the servers. I *wish* we did, but we don't. We have server maintainers who do everything, and then it gets packaged and the game owners just install it and run it. Many games are running these packages from versions that were last up-to-date sometime pre-2000. So they're not going to be getting new versions with keepalives even if the servers put out those versions.

It'd be preferable, really, if new servers had keepalive systems *and* the client did, to handle both old clients and old servers which don't. If the server can implement it without the client doing anything, though, it stands to reason that the client ought to likewise be able to implement it without server support. If it had to be two-sided, the versions already out there wouldn't work. There's no logic to the claim that it can't be done in the client if the servers--and not just the one that does it with special commands--can manage it on their own.

Ksilyan: http://www.pennmush.org/mail-archive/pennmush/2003-September/001554.html
It's talking about setting things on TCP sockets. It's not just having people send a command or sending some text to the user, which would be layer 2, wouldn't it?

[Go to top] top
Posted by Flannel   USA  (1,230 posts)  [Biography] bio
Date Mon 29 Aug 2005 07:25 PM (UTC)  [ quote  ]
Message
Actually, have you tried sending a KeepAlive packet?
Hmm, I would think if the server doesn't support it, you would end up closing your connection (maybe?) if done by the OS (as it wouldn't get a response?).
But, if you're sending via your client, it would serve to keep your connection alive (as you would be sending packets) and, your server might not count it as sending something (or it might, but I imagine it wouldn't display it).
It's worth a try, either way.

Documentation:
http://www.dslreports.com/faq/7792

Talks about what keepalive is (I thought it was coming the other way), and how to change your operating system default timeout period, but if TinyMush doesnt support that, I think it would close the connection (not at the NAT, but at the OS, thinking the server had died).
~Flannel

Messiah of Rose
Eternity's Trials.

Clones are people two.
[Go to top] top
Posted by Flannel   USA  (1,230 posts)  [Biography] bio
Date Mon 29 Aug 2005 07:12 PM (UTC)  [ quote  ]
Message
She was saying that her server people said "its the client's problem" when you were saying "its the servers problem".

But, we were talking about two different things. We were talking about how to implement a keepalive system, she just wants her NAT not closing her connection (but there's no support for it on the server side). It really is 'the clients problem' as you 'chose' to play through a router that drops you after a certain amount of time.

Unfortunately, without sending something to the server, there isn't any way to keep your connection alive. And, unless you can do some negotiation (like pretending to be interested in MXP, or whatever else) which doesn't reset your idle time (it may or may not, it would depend on the server I think), then your timer is going to be reset whenever you do it.
~Flannel

Messiah of Rose
Eternity's Trials.

Clones are people two.
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Mon 29 Aug 2005 07:09 PM (UTC)  [ quote  ]
Message
That's the thing... if the server implements its own version of these keepalives, then the problem is trivial. But Neva stated that it's not acceptable to expect such an implementation nor is is acceptable to ask for it to be implemented, so this whole set of possibilities is basically ruled out.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Flannel   USA  (1,230 posts)  [Biography] bio
Date Mon 29 Aug 2005 07:08 PM (UTC)  [ quote  ]
Message
And having the specs in the first place. In it's most basic form, it's a plugin with one trigger (and two entities), and actually, that trigger would probably end up being a callback.
But, if we don't know what to look for and send back, we can't help.
~Flannel

Messiah of Rose
Eternity's Trials.

Clones are people two.
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Mon 29 Aug 2005 07:07 PM (UTC)  [ quote  ]
Message
[You posted your post as I was writing mine.]

Quote:
which makes it interesting that Ksilyan's response is the exact opposite.
Would you mind elaborating a bit on that? I don't want you putting any words in my mouth... :)
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Mon 29 Aug 2005 07:04 PM (UTC)  [ quote  ]
Message
Flannel: yes, sending an empty packet is one possibility, as I mentioned. But again, that depends on the TCP/IP library not throwing away empty packets - and it's not unreasonable for a library to do just that. As for SO_KEEPALIVE, it seems that that is non-standard, which can create problems.

Neva, I'm not trying to talk you down. What I am trying to say is that you're not registering what I'm telling you, either that or you're not reading it. Sure, lots of programs implement their own versions of keepalive. But how do you know whether or not they do it on layer 1 or layer 2 of the communication? If they do it on layer 2 - which is quite likely - then, translated to our particular situation, the game server has to be changed. You already stated that is not an option, so . . . that pretty much rules out that entire set of possibilities, doesn't it?

As for this:
Quote:
If the instructions could be sent without text,
I already mentioned that; I also mentioned before (and to Flannel just now) that that solution depends completely on the library not throwing away empty packets. After all, in the vast majority of cases, it is a good thing to not send data if there's nothing to send.

As a final note, what you're asking for is actually trivial. With, of course, the disclaimer of everything I've said... For instance, the TCP/IP keepalive business is just a matter of setting a flag. That's one line of code. But it's a non-standard flag. And that's not non-standard in the sense of MXP. It's a much more fundamental "non-standardness" than that. That is what I feel you have not accepted yet: it really isn't a question of programming difficulty, it is a question of programming feasibility and good practice.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Neva   USA  (117 posts)  [Biography] bio
Date Mon 29 Aug 2005 07:03 PM (UTC)  [ quote  ]
Message
TinyMUSH doesn't have any sort of capabilities for them. (When suggested, the response was basically 'go to hell, that's the client's problem', which makes it interesting that Ksilyan's response is the exact opposite.) TinyMUX has something coded into the server, but that's not doable for most of us, since the average player has no control over what server the game s/he plays uses. PennMUSH has something which uses the aforementioned non-standard keepalive extension. I don't know how well it works, because I don't know of anybody who plays on a Penn-based game right now. (Not that people don't, just not my circle of friends.)

Because the problem of the connection timeouts is on the client's side of things--not actually in the client, but in the client's computer's connection to the computer, and therefore really not the server's problem--it seems like a fairly reasonable thing to see if the client can be made to do something (send an empty packet periodically, use the keepalive extension, hop on one foot and sing, I'm not picky as long as it has the desired effect) which would send data through the connection, making sure the NAT doesn't close it, without the MU* server registering it as a command.

For the time being, the option favored to keep the connection going is a timer with '@@' or some other command which produces no result, but that still tells the server you're there when you aren't. I don't know, because I don't do a lot of scripting anymore, if any of these other options are things that plugins are capable of or not. If so, then terrific, it just seems to be something deep enough into the way the client actually operates that it might not be scriptable.

In which case, it's the sort of thing Nick could look into.
[Go to top] top
Posted by Flannel   USA  (1,230 posts)  [Biography] bio
Date Mon 29 Aug 2005 06:47 PM (UTC)  [ quote  ]

Amended on Mon 29 Aug 2005 06:50 PM (UTC) by Flannel

Message
Ksilian, it might be a simple case of the server sending a certain packet, and expecting a response (SO_KEEPALIVE, and expecting an ACK response like). Which is doable in mushclient (with a plugin none the less!).

But honestly, I can't find ANY documentation on this for TinyMush, so we really can't tell. Neva, do you have any links or blips or anything about what is actually going on with these keepalive things?

Edit:
And if there are different implementations for different servers (provided they all work as plugins) then I would think that it'd be best left up to a plugin to do the work. It doesn't require further integration, and there is no standard way of doing it, there will have to be a bunch of options about it (or at least a dropdown list) and we would never really be able to know for sure if we got them all.
~Flannel

Messiah of Rose
Eternity's Trials.

Clones are people two.
[Go to top] top
Posted by Neva   USA  (117 posts)  [Biography] bio
Date Mon 29 Aug 2005 06:45 PM (UTC)  [ quote  ]
Message
I'm well aware of the two layers of communication. I understand this. I'm not a programmer, but I'm also not stupid, thank you. Proxies aren't magical checkboxes either. But if you don't have them turned on, your connection works just the same way it always did. When it's turned on, the client routes it through a different server as instructed.

I'm not especially concerned with the technical manner of doing this because there's not just one, as it evidenced from the number of other programs, servers and otherwise, which maintain network connections of all sorts in whatever way they see is best. No, it's not trivial, in terms of the time it might need to implement it, but a lot of features in MUSHclient haven't been.

But going into that, one part of the packet is the text it's sending and the other part are the associated instructions with the packet. Again, not a programmer, but not stupid. If the instructions could be sent without text, then this would also serve as activity on the connection and prevent the NAT from timing it out. Or the optional keepalive part could be used, as a part of the connection options which must be set before each connection, and left out when not in use, depending on how that interacts with servers which don't work with it. I don't know that, but to be honest, it doesn't sound like you do, either.

I resent being talked down to in this manner, and I really don't understand why you're so dead set against the developer of this particular software package taking the time to actually evaluate this proposal. You're not the one who has to do the code, so maybe you could leave it up to the guy who does. Nick's implemented a number of things along the way which have to have been at least as complicated as this (if not moreso, imagining the amount of time that's gone into scripting since it first went in), and I hardly think it's impossible.
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Mon 29 Aug 2005 06:23 PM (UTC)  [ quote  ]
Message
No, it is NOT the same. It's not just a question of adding a magic checkbox that magically makes this stuff work over a magically powerful internet connection. There are some serious technical issues here, and every time I try to tell you about them you brush them aside as if they were meaningless.

The problem here is quite trivial. You're speaking from a user's perspective and I'm speaking from a technical perspective. I have the impression that either you did not read or you did not register what I said about the two layers of communication. It'd be a lot easier if you worked with me instead of continuously ignoring the problems I bring up. If you want me to rephrase or explain the problems, then just say so. But please don't just brush them aside and repeat yourself.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

6,662 views.

This is page 1, subject is 2 pages long: 1 2  [Next page]

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page

Go to topic:           Search the forum

[Go to top] top

[Home]

Written by Nick Gammon - 5K

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Internet Contents Rating Association (ICRA) - 2K]    [Web site powered by FutureQuest.Net]