[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]  MUDs
. -> [Folder]  General
. . -> [Subject]  Suggested protocol for server to client "out of band" messages
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?
Suggested protocol for server to client "out of band" messages

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

Pages: 1  2  3  4  5  6  7  8 9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  

Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Reply #105 on Fri 05 Feb 2010 04:39 AM (UTC)  [ quote  ]
Message
Nick Gammon said:
So that is a lot simpler than mucking around grabbing stuff out of packets. :)


Yeah, really. O_o I've been mucking around with writing a telnet state machine to filter out ATCP data. (I'm still working out the kinks XD)

I assume multiple plugins can implement these callbacks without clashing?
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top
Posted by Nick Gammon   Australia  (18,801 posts)  [Biography] bio   Forum Administrator
Date Reply #106 on Fri 05 Feb 2010 04:49 AM (UTC)  [ quote  ]
Message
Yes indeed. Any number of plugins could get the callback.

In fact, it could be a lot simpler for each plugin to just parse the ATCP lines, which so far look really simple, than have some sort of "master" module do that, and pass that around to the others. A simple Lua regexp would do that.

Then each plugin could stand alone (which is really what I was suggesting in page 1 of this thread) so you add and remove them as you want, without needing to ensure that some "central" plugin was there as well.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Reply #107 on Fri 05 Feb 2010 05:56 AM (UTC)  [ quote  ]
Message
Yeah, that makes a lot of sense. I think I will keep working on the core ATCP plugin, though, because some of the features I'm adding will be very useful. For example, I'm seeking the IAC GA sequence at the end of the Achaea prompt, and shipping the states of the current ATCP messages to registered plugins. This is useful because a plugin might (and often does) want multiple pieces of data before it can do something.

I'm not sure how easy it would be to integrate that IAC_GA-sensing technique with the new plugin callbacks you added, since I don't see any way to notice GA after all the ATCP messages are received except through OnPluginPacketReceived. And I would imagine that OnPluginPacketReceived is called -before- the new callbacks, since the new callbacks represent a certain amount of packet processing.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top
Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Reply #108 on Fri 05 Feb 2010 07:56 AM (UTC)  [ quote  ]
Message
I was reading over the v4.48 changelist, and I noticed this line:

Quote:
In the case of type 102, then OnPluginTelnetOption is called instead (without the option number, as that is fixed at 102). This is for backwards compatibility

Why "instead"? Why not use OnPluginTelnetSubnegotiation if available, and fall back to OnPluginTelnetOption otherwise?
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top
Posted by Nick Gammon   Australia  (18,801 posts)  [Biography] bio   Forum Administrator
Date Reply #109 on Fri 05 Feb 2010 06:56 PM (UTC)  [ quote  ]
Message
I'll just call them both, that is simpler than having stuff like "call one script if the other doesn't exist".

That way new plugins can just use OnPluginTelnetSubnegotiation for all message types.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Nick Gammon   Australia  (18,801 posts)  [Biography] bio   Forum Administrator
Date Reply #110 on Fri 05 Feb 2010 07:44 PM (UTC)  [ quote  ]
Message
For sake of completeness in documentation, I have decided to treat the sequence:


IAC SB n <some data> IAC x


... where x is neither IAC or SE as if x is SE.

In other words;


  • The subnegotiation sequence, although incorrectly terminated, is processed as if it were correctly terminated.

  • The sequence IAC x does not start a new command sequence.

  • The character x does not form part of the input stream.


I believe this treatment:


  • Is not inconsistent with all the existing specs I have seen - that is, I have not seen an official document that suggests that it be done differently.

  • Discourages server writers from trying to "save a byte" by omitting the SE.

  • Discourages server writers from trying to save two bytes by switching from one sequence to another, as they might be tempted to do, if you treated it as:

    
IAC SB n <data> IAC SE IAC x


  • Keeps the state machine simple.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Nick Gammon   Australia  (18,801 posts)  [Biography] bio   Forum Administrator
Date Reply #111 on Fri 05 Feb 2010 09:24 PM (UTC)  [ quote  ]
Message
Version 4.48 has been released now, so if you ATCP experts want to try it out, I would be grateful.

You should be able to use a plugin callback similar to the one earlier on the page to easily extract out the ATCP data.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Nick Gammon   Australia  (18,801 posts)  [Biography] bio   Forum Administrator
Date Reply #112 on Sat 06 Feb 2010 12:31 AM (UTC)  [ quote  ]
Message
David Haley said:

I'll fess up straight away that I don't really see the advantage of this over, say, ZMP. I don't know ATCP but apparently it does something kinda similar. But really, this kind of protocol exists, and ZMP at least is quite simple, and it's easier to define semantics in ZMP using the package/command mechanism. (ZMP is also very easy to parse.)


I've tried to find a MUD that implements ZMP, without a heap of success. Some of the pages that are supposed to be about ZMP are in fact just advertising:

http://www.awemud.net/zmp/draft.php

A claimed implementation, TeensyMud, doesn't seem to exist, or be up.

If I could find a ZMP MUD I could perhaps check that MUSHclient can parse the protocol - at least at the low level, the part that has the 0x00 bytes in it. So if you could advise me of an active one, that would be great.

But if not, your original question is:

"Why did you develop your own protocol and not use <a protocol that is much better but that absolutely no-one uses>?"

And I would reply, "well, why does no-one use this better protocol then?".
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Reply #113 on Sat 06 Feb 2010 03:32 AM (UTC)  [ quote  ]

Amended on Sat 06 Feb 2010 03:33 AM (UTC) by David Haley

Message
It's hard to get people to adopt a fundamentally client-driven protocol when you're not in the business of writing clients. ;)
For instance, MXP would have had far less success -- even considering the relatively small success it has now -- had it not been written and pushed by somebody who happened to be the author of one of the major clients.

Client authors get to set standards, much like how web browser authors get to set (mis)standards. That's why I'm pushing the strong, standardized spec here, because whatever ends up happening is likely to become a standard to some extent, by accident or by design.



As to MUDs that run ZMP, you'd have to ask Elanthis. Supposedly he has a program called 'SourceMUD' that runs ZMP. And there were some mentions in the threads on MB, but I don't know if any of them became public releases.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Reply #114 on Sat 06 Feb 2010 09:44 PM (UTC)  [ quote  ]
Message
I just remembered one big, major reason why the ATCP core plugin is still important: the protocol requires a single 'hello' message to be sent before anything else, listing the packages that you want to be enabled. Single plugins could do it on their own, but only the first hello message the server receives is taken into account.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top
Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Reply #115 on Sat 06 Feb 2010 10:08 PM (UTC)  [ quote  ]

Amended on Sat 06 Feb 2010 10:09 PM (UTC) by Twisol

Message
I'm modifying a copy of my ATCP plugin to see if I can work the new callbacks into it, and I notice right away that I have a problem with the hello message. By returning true from OnPluginTelnetRequest, MUSHclient sends IAC DO ATCP, but I need to send the hello message immediately after IAC DO ATCP. Sending the hello message before IAC DO ATCP is very unlikely to work properly, but I can't do it later (after the function returns) either, because I have absolutely no guarantee that nothing else will have been sent by then.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top
Posted by Nick Gammon   Australia  (18,801 posts)  [Biography] bio   Forum Administrator
Date Reply #116 on Sat 06 Feb 2010 11:48 PM (UTC)  [ quote  ]
Message
In the OnPluginTelnetRequest send IAC DO ATCP and then the "hello" message. That way you guarantee it directly follows the "DO". The client then sends a second DO which hopefully won't cause a problem. If it does, try returning false, hopefully the server won't be confused by DO followed by DONT. If that doesn't work, get back to me.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Reply #117 on Sun 07 Feb 2010 12:02 AM (UTC)  [ quote  ]

Amended on Sun 07 Feb 2010 12:05 AM (UTC) by Twisol

Message
Yeah, that definitely didn't work. It threw the client into an infinite loop, it probably flooded Achaea with lots of alternating IAC DO ATCP and IAC DONT ATCP too.

EDIT: Well, an -effective- infinite loop. It wasn't looping forever in the same area of code, but it was doing the same thing over and over again because Achaea kept sending IAC WILL ATCP. At least that's my guess. I wish I had Wireshark running at the time, but I'm not about to unleash that on Achaea again. XD I only know it wasn't a typical infinite loop because the client was still slightly responsive, for example when I killed it through the Task Manager, it asked if I wanted to save my world.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top
Posted by Nick Gammon   Australia  (18,801 posts)  [Biography] bio   Forum Administrator
Date Reply #118 on Sun 07 Feb 2010 12:52 AM (UTC)  [ quote  ]
Message
Yes, well that is tricky to get right. I was thinking of letting you do the IAC DO 200 (and add your hello message) but potentially you might have lots of plugins that then all agree to the protocol, and cause the sort of loop you described. After all, you don't want two "hello" messages, nor do you want zero of them.

I have changed it in 4.49 to do two extra things:

1. Disable negotiation loops, by not processing the WILL or WONT message more than once.


2. After you *agree* to the WILL, your function OnPluginTelnetRequest gets called a second time with "SENT_DO". This lets you do the "hello" message once, at the correct time.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Nick Gammon   Australia  (18,801 posts)  [Biography] bio   Forum Administrator
Date Reply #119 on Sun 07 Feb 2010 08:33 PM (UTC)  [ quote  ]
Message
And also, it now only calls OnPluginTelnetRequest until it gets a positive response. This is so you don't login twice, if you have multiple plugins that might be interested in that protocol.

This lot of fixes is now pushed to GitHub if you want to experiment with a private build.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[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.

61,072 views.

This is page 8, subject is 23 pages long:  [Previous page]  1  2  3  4  5  6  7  8 9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  [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]