02 Apr, 2010, Runter wrote in the 1st comment:
Votes: 0
So, working on implementing MCCP. (in Ruby).

The problem I'm running is purely a lack of understanding of exactly how I'm supposed to generate the correct data for the 'zlib stream.'

Originally, I thought this was as simple as compressing and sending stuff out like:

to_send = Zlib::Deflate.deflate("Something to compress.", 9)


Apparently I'm going to need to do something more like:
#somewhere d being a socket
d.mccp = Zlib::Deflate.new(9) # new zlib stream

#then using this stream something like
to_send = @mccp.deflate(txt, Zlib::SYNC_FLUSH)


Both ways seem to be a fail for clients to understand.

I'm probably missing something, but any insights on the subject would be appreciated.
02 Apr, 2010, Scandum wrote in the 2nd comment:
Votes: 0
Are you sending IAC SB MCCP2 IAC SE right before starting compression?
02 Apr, 2010, Runter wrote in the 3rd comment:
Votes: 0
Scandum said:
Are you sending IAC SB MCCP2 IAC SE right before starting compression?


Yes.


Mushclient reports unrecognized compression method or something. Cmud does something similar but with more garbage printed before the fail.


I've also tested the compression functions to make sure they're working. As far as I can tell I can compress and uncompress between the two. I haven't been able to find a working ruby MCCP implementation.
02 Apr, 2010, kiasyn wrote in the 4th comment:
Votes: 0
I have done this before (wasn't specifically MSSP though, just zlib compression)

Pulling out bits of code from said project…

class MySocket
def initialize
# …
@i_stream = Zlib::Inflate.new
@o_stream = Zlib::Deflate.new
# …
end
def poll
# …
@inbuf << @i_stream.inflate(@socket.readpartial(4096))
# …
end
def send
# …
@socket.write @o_stream.deflate( p.contents, Zlib::SYNC_FLUSH )
# …
end
# …
end
02 Apr, 2010, Runter wrote in the 5th comment:
Votes: 0
kiasyn said:
I have done this before (wasn't specifically MSSP though, just zlib compression)

Pulling out bits of code from said project…

class MySocket
def initialize
# …
@i_stream = Zlib::Inflate.new
@o_stream = Zlib::Deflate.new
# …
end
def poll
# …
@inbuf << @i_stream.inflate(@socket.readpartial(4096))
# …
end
def send
# …
@socket.write @o_stream.deflate( p.contents, Zlib::SYNC_FLUSH )
# …
end
# …
end


Yes, that's what I'm basically doing. But the clients aren't liking that data for some reason for MCCP. I don't think my sockets library could be interfering with the data but maybe it is.
My other option is perhaps writing this using the exact C code and extending it in.
02 Apr, 2010, kiasyn wrote in the 6th comment:
Votes: 0
i think it was especially important to create the zlib instance, and keep reusing it.
02 Apr, 2010, Runter wrote in the 7th comment:
Votes: 0
kiasyn said:
i think it was especially important to create the zlib instance, and keep reusing it.

Yeah, I do that.
30 Jul, 2010, Deimos wrote in the 8th comment:
Votes: 0
I know this is a somewhat stale thread, but it doesn't appear that you ever found the solution to your problem. I took a look at the CoralMUD source, and it appears that you're sending IAC SB MCCP2 IAC SE "\0". Because everything after the subnegotiation has to be on the zlib stream, the trailing "\0" (which isn't on the stream) is likely causing the hiccup. I ran into a similar problem on my own game, so I just thought I'd share.

On a similar note, I have the MCCP negotiation working now, but for some reason MUSH keeps adding erroneous characters onto the end of some (but not all?) of the server output. For example, if I send the string/prompt "test\r\n> ", what actually gets shown on MUSH's output is "test\r\n> \r\n> ". I've triple-checked the data leaving the server, before and after compression, and it's correct, so I don't really know what's going on here. I'll keep messing with it, though.
31 Jul, 2010, Deimos wrote in the 9th comment:
Votes: 0
Well, the issue went away as I was refactoring the MCCP filter class, so apparently I was missing something obvious. I've also added negotiation now (IAC WILL COMPRESS2, then wait for IAC DO COMPRESS2 response before starting the subnegotiation), and everything appears to be working well.
02 Aug, 2010, Runter wrote in the 10th comment:
Votes: 0
Ah. I appreciate your post. I had all but given up on a solution. Ill definitely look into it once I'm back in the civilized world.
0.0/10