14 Mar, 2009, Scandum wrote in the 22nd comment:
Nick Gammon said:
I qualify my comment in the other thread here. MUSHclient *does* impose a limitation of around 100 characters on telnet subnegotiations, on the grounds that if you haven't turned on or off an option in 100 characters something is seriously wrong.
However we (that is Lasher and myself) did not intend telnet negotiations to be used for the bulk exchange of data between client and server.
However we (that is Lasher and myself) did not intend telnet negotiations to be used for the bulk exchange of data between client and server.
If you look at rfc1572 subnegotiations can easily go over 100 bytes, and a MSSP subnegotiation is somewhere around 700 bytes. 2000 bytes is probably a better cut off point.
14 Mar, 2009, Tyche wrote in the 23rd comment:
I don't really remember why I was concerned about buffer size. It likely did have to do with file transfer, because I remember wanting users to be able to edit images. It's possible my concerns revolved around defensive programming, and in that regard it doesn't really matter what you negotiate because you ought not trust it to be true anyway. So the issue is probably one of policy rather than protocol. Sort of a quota policy, which I don't think ZMP can solve, rather it translates into a set of configuration options that someone building a general network stack for a mud should make available to anyone using it.
14 Mar, 2009, David Haley wrote in the 24th comment:
Les said:
For better or worse, yes. :) There's some contortions for the triggers' sake for lines broken across packets but that's what we do.
David Haley said:
Ah – so you don't actually process triggers on line-end, you process on packet end?
My understanding was that many clients process triggers on a per-line basis, meaning that they would be vulnerable to a malicious server sending a huge amount of normal text and perhaps causing the process to run out of memory (unless it guards against a maximum line length or something).
My understanding was that many clients process triggers on a per-line basis, meaning that they would be vulnerable to a malicious server sending a huge amount of normal text and perhaps causing the process to run out of memory (unless it guards against a maximum line length or something).
For better or worse, yes. :) There's some contortions for the triggers' sake for lines broken across packets but that's what we do.
So now I fess up and say that my point was that if clients are already vulnerable to a malicious server sending a huge single line, worrying about a malicious server sending a huge ZMP command is nothing new. :smile:
Les said:
Sure you could do this but there isn't a solution other than disconnecting from the mud since there is no telnet protocol way to terminate a subnegotiation. So since the only options would be wait and see or disconnect I would vote for just defaulting to disconnect and informing the user their server is b0rked ;)
Well, in some cases there would be a legitimate reason for it to take a while. I'm thinking something like the Firefox message: "a script is taking too long to execute, do you want to wait or abort?" I agree though that it is likely the server is messed up, but it also be simply that the connection is experiencing some lag right then and the rest of the data is on its merry way or something like that.
14 Mar, 2009, elanthis wrote in the 25th comment:
I updated the official draft with the unlimited parameters language and the 16KiB minimum buffer size requirements.
http://zmp.sourcemud.org/spec.shtml
Also cleaned up a few bad terminology choices (replaced 'argument' with 'parameter' and 'sub-request' with 'subnegotiation').
I've got a half-written spec for the subwindow stuff, but it's surprisingly slow going for me. I really hate writing documentation, especially when I'm not getting paid for it. ;) Should have that up later today.
http://zmp.sourcemud.org/spec.shtml
Also cleaned up a few bad terminology choices (replaced 'argument' with 'parameter' and 'sub-request' with 'subnegotiation').
I've got a half-written spec for the subwindow stuff, but it's surprisingly slow going for me. I really hate writing documentation, especially when I'm not getting paid for it. ;) Should have that up later today.
Random Picks
I honestly don't see how this can work reliably. For a start, there is no guarantee that a server will split up the data it wants to send in logical places (as it is likely to buffer lines and pull them out of a buffer in packet-size chunks), and packets can be segmented during transmission. Thus a trigger that should match on "David attacks you" could easily fail because the packet ends with "David att".