Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Due to spam on this forum, all posts now need moderator approval.
Entire forum
➜ MUSHclient
➜ Plugins
➜ trying to make atcp2 plugin to work
|
trying to make atcp2 plugin to work
|
It is now over 60 days since the last post. This thread is closed.
Refresh page
Pages: 1
2
3
4
5 6
7
8
9
| Posted by
| Twisol
USA (2,257 posts) Bio
|
| Date
| Reply #60 on Wed 28 Jul 2010 05:08 AM (UTC) Amended on Wed 28 Jul 2010 05:09 AM (UTC) by Twisol
|
| Message
| (Quoted out of order for ease of responding)
Nick Gammon said:
But for the client to do it, every plugin would need to know exactly what every other plugin needs, which surely is far too much interdependency?
Ehm... no. The central GMCP plugin keeps track of what the others want, and the others only deal with themselves.
Nick Gammon said:
I don't see how either end can safely remove modules. The server won't know if the client has had a plugin crash, which stopped it removing a module. Or indeed the client might erroneously remove the module once too often.
The central plugin should reasonably be able to tell, using refcounting, whether or not it should add or remove a module. With MUSHclient, you can use OnPluginListChanged to tell if a plugin disappeared. The only issue arises when you introduce multiple "central plugins", which is really more of a non-issue.
Nick Gammon said:
I would suggest that, if both the client and server are designed to cope with a certain number of message types (eg. room changes, battle information, inventory) then once requested, they should be sent until the connection is broken. After all, the player installing a module, and then removing it, but remaining connected for weeks, is surely an unlikely scenario? And if the system can't cope with that many messages, then you have a problem in the first place.
The player doesn't touch GMCP. The plugins that use GMCP do, and they can enable/disable modules as they please. As a very off-the-cuff example: You might have a plugin tracking your stats and your inventory, and you could disable the inventory tracking feature, so it can disable the associated module.
I also don't think it's so much about the system as it is the network bandwidth being used. If you don't need it, why send it? |
'Soludra' on Achaea
Blog: http://jonathan.com/
GitHub: http://github.com/Twisol | | Top |
|
| Posted by
| Nick Gammon
Australia (23,133 posts) Bio
Forum Administrator |
| Date
| Reply #61 on Wed 28 Jul 2010 05:38 AM (UTC) |
| Message
|
Twisol said:
If you don't need it, why send it?
My point is that if you are so concerned about something that the player is using some of the time (eg. inventory) but it uses so much bandwidth that you must disable it the moment the player stops wanting to see his inventory (and when would that happen, I ask?) well aren't you on the cusp of having major problems if one more player joins the game?
Too little gain for too much pain, is my attitude to that. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Twisol
USA (2,257 posts) Bio
|
| Date
| Reply #62 on Wed 28 Jul 2010 05:44 AM (UTC) Amended on Wed 28 Jul 2010 05:47 AM (UTC) by Twisol
|
| Message
| If the modules themselves have implicit contracts when they're enabled - that is, if they expect you to do something with the transferred data, as opposed to being a passive recipient - then yes, you may very well want to disable a module.
I don't think it's painful in the least, and I do believe there is gain involved. It's a lot more flexible and future-proof. GMCP is not a closed standard; modules can be developed and used that we never thought of. It is in our best interests to stay flexible, and a refcounting scheme like the one I showed is very simple to implement.
Also, all this is purely client-side. If the client has no need for plugins, it doesn't need to use this. The .Add message is wholly opt-in. If you don't want it, don't use it. |
'Soludra' on Achaea
Blog: http://jonathan.com/
GitHub: http://github.com/Twisol | | Top |
|
| Posted by
| Nick Gammon
Australia (23,133 posts) Bio
Forum Administrator |
| Date
| Reply #63 on Wed 28 Jul 2010 06:05 AM (UTC) |
| Message
| Sure, if you don't need a group of messages, don't ask for them. But once requested, surely the case of changing your mind is infrequent?
Here is an analogy (not perfect, I know) ...
Say you ring up the Acme Electricity Company and ask to have the power connected to your house. Now if you didn't do that, you wouldn't have power. But having done it, you don't ring them back and say "ah, can you disconnect the power on Tuesday nights please? I go out then and don't need it". The extra work of disconnecting and reconnecting, and keeping track of when it is needed and when it isn't, is not worth it. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Twisol
USA (2,257 posts) Bio
|
| Date
| Reply #64 on Wed 28 Jul 2010 06:30 AM (UTC) |
| Message
| I'm not so sure about that analogy! If you're going away for a short time, you certainly may want to shut off your utilities until you get back.
And again, we don't want to make assumptions about the messages being sent. If we think of GMCP modules as TV channels, there are some you become interested in and want to subscribe to, but over time your interests change and you're no longer interested in watching QVC! ;)
Which raises the question: Do you have QVC in Australia? That analogy might not make sense if you don't... |
'Soludra' on Achaea
Blog: http://jonathan.com/
GitHub: http://github.com/Twisol | | Top |
|
| Posted by
| David Haley
USA (3,881 posts) Bio
|
| Date
| Reply #65 on Wed 28 Jul 2010 06:34 AM (UTC) |
| Message
| Look, it simply hasn't been justified beyond abstract principle that modules need to be deactivated. Come up with any plausible example, anything, and we can talk. But thinking about things we never thought of, and creating non-trivial complexity as a result, is just not productive. If something can't be motivated beyond "we might need it but we don't know why", it's not worth pursuing.
New messages can be added, so if it comes to it, this can be added later and everybody will be happy. |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | | Top |
|
| Posted by
| Twisol
USA (2,257 posts) Bio
|
| Date
| Reply #66 on Wed 28 Jul 2010 06:46 AM (UTC) |
| Message
|
David Haley said:
non-trivial complexity
It's not non-trivial! I already showed how simple it was to implement plugin refcounting to deal with plugins each having different needs. And the Core.Supports.Add message is purely opt-in. So if it bothers you so much, just don't use it. |
'Soludra' on Achaea
Blog: http://jonathan.com/
GitHub: http://github.com/Twisol | | Top |
|
| Posted by
| Nick Gammon
Australia (23,133 posts) Bio
Forum Administrator |
| Date
| Reply #67 on Wed 28 Jul 2010 06:47 AM (UTC) |
| Message
|
Twisol said:
Which raises the question: Do you have QVC in Australia? That analogy might not make sense if you don't...
Not that I'm aware of. A quick search seems to indicate it is something to do with home shopping. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| David Haley
USA (3,881 posts) Bio
|
| Date
| Reply #68 on Wed 28 Jul 2010 06:51 AM (UTC) |
| Message
| It's unrealistic to say that a scheme that involves turning modules on and off based on various events prone to race conditions is "non-trivial" and "simple".
Let me turn this around to you: if it bothers you so much, implement it yourself as an extension, but don't force the spec to deal with it for you. You're creating a lot of work (even if you think it's easy, in this hand-waving stage of abstract principles) and you haven't even motivated anything yet beyond "oh, maybe, dunno, might need it". |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | | Top |
|
| Posted by
| Twisol
USA (2,257 posts) Bio
|
| Date
| Reply #69 on Wed 28 Jul 2010 06:51 AM (UTC) |
| Message
|
Nick Gammon said:
Twisol said:
Which raises the question: Do you have QVC in Australia? That analogy might not make sense if you don't...
Not that I'm aware of. A quick search seems to indicate it is something to do with home shopping.
Heh, that's the one. My mother seems to watch it more during the Christmas season. Gift-giving ideas, see. |
'Soludra' on Achaea
Blog: http://jonathan.com/
GitHub: http://github.com/Twisol | | Top |
|
| Posted by
| Twisol
USA (2,257 posts) Bio
|
| Date
| Reply #70 on Wed 28 Jul 2010 06:55 AM (UTC) |
| Message
|
David Haley said:
It's unrealistic to say that a scheme that involves turning modules on and off based on various events prone to race conditions is "non-trivial" and "simple".
Ehm... what race conditions? If a plugin, for one reason or another, doesn't need the data anymore, you decrement the refcount. Once it's 0, you turn it off. If a module moves into positive numbers, you enable it. And MUSHclient is largely single-threaded, which makes thread-related race conditions a non-issue (for it at least).
The messages should only be sent from one place (i.e. one plugin). Other plugins should never .Add or .Remove them themselves. That's why the core plugin handles the Core module, see. |
'Soludra' on Achaea
Blog: http://jonathan.com/
GitHub: http://github.com/Twisol | | Top |
|
| Posted by
| Nick Gammon
Australia (23,133 posts) Bio
Forum Administrator |
| Date
| Reply #71 on Wed 28 Jul 2010 07:00 AM (UTC) |
| Message
| I haven't yet had a concrete example of some message, that might initially be enabled, but you then decide to turn off (your inventory list maybe?). And nor have I had it explained why, if you don't turn it off, and it is really important to, to save bandwidth, how the server will cope?
Let me put it this way, after spending quite a bit of frustrating time with this when we were doing optional messages in Aardwolf, where the server and client never seemed to be in sync, that I thought ... right! Next time:
- Messages will be out-of-band (eg. telnet subnegotiation) so it doesn't matter if you get more messages than you need at this particular moment.
.... and ....
- You get the lot.
If the server can't cope with every client getting every message, then there is fundamental design flaw. You can however reduce the bandwidth with caching.
I still find it kind of odd that the caching proposal was dismissed as "interesting, we might look into that one day in the distant future", but a lot of effort is being put into switching messages on and off (with the same overall concept of saving bandwidth). But, and this is the big but, the switching messages off only works if the player chooses not to get a particular message (maybe they don't care what is in their inventory?). However caching saves bandwidth all the time. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Worstje
Netherlands (899 posts) Bio
|
| Date
| Reply #72 on Wed 28 Jul 2010 07:10 AM (UTC) |
| Message
| I couldn't help but smile as I read Nick's post just now. By that logic, there would be no issue to a persistent cache to help lower bandwidth across different sessions, but that on the other hand was shot down as being unnecessary.
Sorry for the derail. The amusement overtook me. :) | | Top |
|
| Posted by
| Twisol
USA (2,257 posts) Bio
|
| Date
| Reply #73 on Wed 28 Jul 2010 07:11 AM (UTC) Amended on Wed 28 Jul 2010 07:13 AM (UTC) by Twisol
|
| Message
| Lets take caching as an example. Do you remember my competing proposal, that removed the hash parameter from the other modules and relied on the 'id' to refer between them? It required that you take action on that incoming message by sending a 'get' with the provided hash, which would then respond with the cached data. And the cached data is not longer sent in other messages, if you recall, so you can't get at it immediately that way.
Now lets say you don't care about caching anymore. You can't just ignore the Cache module, because its presence is keeping the data out of the other messages. So you disable the cache module. |
'Soludra' on Achaea
Blog: http://jonathan.com/
GitHub: http://github.com/Twisol | | Top |
|
| Posted by
| David Haley
USA (3,881 posts) Bio
|
| Date
| Reply #74 on Wed 28 Jul 2010 07:14 AM (UTC) |
| Message
| Worstje: What? Nick's caching proposal was persistent across sessions...
Quote:
Now lets say you don't care about caching anymore. You can't just ignore the Cache module, because its presence is keeping the data out of the other messages. So you disable the cache module.
It's not useful to provide contrived examples of doing something silly that then breaks things. A much better question is: why would you actually do such a thing? Only once that question is answered is it worth spending any time whatsoever on how to deal with the consequences. |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | | 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.
306,150 views.
This is page 5, subject is 9 pages long: ![[Previous page]](/images/thin_prev.gif)
1
2
3
4
5 6
7
8
9
![[Next page]](/images/thin_next.gif)
It is now over 60 days since the last post. This thread is closed.
Refresh page
![[Go to top]](/images/gototop.gif)
top