Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to "verify" your details, 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.
 Entire forum ➜ MUSHclient ➜ Plugins ➜ Question about OnPluginPacketReceived and compression
Question about OnPluginPacketReceived and compression

It is now over 60 days since the last post. This thread is closed.     Refresh page

Posted by David Haley   USA  (3,881 posts)  Bio
Date Mon 12 Apr 2010 07:20 PM (UTC)
Message
The documentation, http://www.gammon.com.au/scripts/doc.php?general=plugin_callbacks, says this:

Quote:
OnPluginPacketReceived
--
-- MUSHclient has received the packet 'sText'
--
function OnPluginPacketReceived (sText)
end -- function



This function is called when each incoming packet (data) arrives from the MUD. A packet does not necessarily start or end on line boundaries, and may consist of partial lines, or more than one line.

You can return data from this function (in version 3.59 onwards). If you do, then the returned data will replace the incoming data. In other words, you can change words, omit lines, add new lines, and MUSHclient will proceed as if the altered line had arrived from the MUD.




In practice, I believe that the text you get here is the uncompressed text, i.e., after the MCCP layer has been processed. The documentation is slightly misleading as to this fact, although I read it to mean that decompression has already taken place because it speaks of words, lines, etc.

Could the documentation perhaps be reworded to clarify that the packet is post-compression? (Or is that not actually the case?)
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 #1 on Mon 12 Apr 2010 07:23 PM (UTC)
Message
I've used OnPluginPacketReceived perfectly well in the face of compression, and my data was always the decompressed text. I'd be in favor of documentation clarification, certainly.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Nick Gammon   Australia  (23,052 posts)  Bio   Forum Administrator
Date Reply #2 on Mon 12 Apr 2010 09:41 PM (UTC)
Message
It *is* post-decompression. I have amended the documentation for the next release to clarify that.

I also mention that you may get a packet with both compressed and uncompressed data, which is the packet in which compression is turned on.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #3 on Mon 12 Apr 2010 10:38 PM (UTC)
Message
Nick Gammon said:
I also mention that you may get a packet with both compressed and uncompressed data, which is the packet in which compression is turned on.


Interesting, why does it work that way? Couldn't it stop at the enable-compression mark, call OnPluginPacketReceived for that data, then start decompression and call it again? I don't think it's at all desirable to let compressed data through like that. :|
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #4 on Mon 12 Apr 2010 10:40 PM (UTC)
Message
I would be inclined to agree, since after MCCP is negotiated the nature of the stream changes somewhat. Otherwise, the plugin would need to, in principle, check every packet to see if it contains part-uncompressed and part-compressed data. It would also mean that you couldn't read that compressed data, which could be important.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Nick Gammon   Australia  (23,052 posts)  Bio   Forum Administrator
Date Reply #5 on Tue 13 Apr 2010 08:44 AM (UTC)
Message
It gives you the packet. It hardly can be expected to know about a state change in the middle of the packet, which may or may not occur (depending on whether you have disabled compression).

It doesn't have to check *every* packet, once compression is turned on you don't have to check again.

Asking to stop at the compression marker is like asking for the packet to be pre-processed.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #6 on Tue 13 Apr 2010 01:43 PM (UTC)
Message
Yes, I guess that it is asking for a form of preprocessing. But then again, post-MCCP-enabling, packets are preprocessed. Although you don't have to check every packet, the plugin function would still need the logic:


function OnPluginPacketReceived(...)
  if mccp_is_off then
    check_packet_for_stuff(...)
  else
    do_normal_processing(...)
  end
end


What confuses me is that the function seems to do different things depending on whether MCCP is disabled or enabled. When disabled, it gives you the literal packet. When enabled, it preprocesses it by decompressing it. And then in the transition packet, it does both.

In practice this is probably not usually a problem; I'm not even sure that servers will send text immediately after the compression marker. But if they do, then it seems that data could be lost unless plugin authors are quite careful with how they handle these packets.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Nick Gammon   Australia  (23,052 posts)  Bio   Forum Administrator
Date Reply #7 on Tue 13 Apr 2010 11:42 PM (UTC)
Message
It gives you the packet before processing, as some people (like Twisol) pulled out or amended ATCP codes, so they had to get it before it hit the MUSHclient state machine.

Switching to compression is just one of the things the state machine might do (if compression was enabled for this world file).

Afterwards, yes I agree you get the post-decompressed packet, but in a sense it is the same. It is still the data before it is sent to the state machine.

I am not totally recommending that people modify incoming packets. To do so would suggest that the client lacks some fundamental feature. For example, recently the telnet subnegotiation was added to the core client, making it unnecessary to do that "manually".

For worlds where you know it will turn on MCCP, and you are planning to use it, it would be simple enough to do nothing in the OnPluginPacketReceived until compression was switched on. Hopefully nothing really important comes in those first few packets.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #8 on Wed 14 Apr 2010 07:43 PM (UTC)
Message
Oh, that makes sense -- I forgot that switching to compression would be part of the normal state machine.

Quote:
Hopefully nothing really important comes in those first few packets.

:-P


Well, I agree that this isn't a problem big enough to warrant a non-trivial change.

There are probably very few reasons to be looking at individual packets anyhow; as you say the new telnet functions in the core make this far less necessary (in fact I can't think of a reason to do so, unless you're doing something funny with your own binary protocol without subnegotiations -- but that'd be pretty weird).
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.

23,410 views.

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home