<html><head/><body><html><head></head><body>Hi -<br>
<br>
I guess so... however that while loop behavior with many reallocs per frame for payload data is objectionable, I have my eye on removing the looping for a different scheme.<br>
<br>
It's probably better to work with the latest release fwiw, it's certainly easier to take care of bugs there.<br>
<br>
-Andy<br><br><div class="gmail_quote">Larry Hayes <lhayesg@gmail.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Andy,<br /><br />Thanks for the time looking into it.<br /><br />I tried v1.1 this morning and it works.<br /><br />I am assuming this is a v1.0 issue.<br />I do not see LWS_MAX_ZLIB_CONN_BUFFER defined in 1.0.<br />I did notice in v1.0 there is no while loop around the inflate as there is in v1.1<br />
<br />Larry<br /><br /><div class="gmail_quote">On Tue, Feb 12, 2013 at 9:42 PM, "Andy Green (林安廸)" <span dir="ltr"><<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a>></span> wrote:<br /><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 13/02/13 05:32, the mail apparently from Larry Hayes included:<div class="im"><br />
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am using v1.0 of the library.<br />
Configure Options:  --disable-static --enable-shared --enable-openssl<br />
--enable-libcrypto --with-client-cert-dir=xxxx<br />
<br />
This is a NON-SSL web socket connection.<br />
<br />
I create both the Client and Server to support the<br />
libwebsocket_internal_<u></u>extensions.<br />
<br />
My question is should deflate-frame extension support more than the<br />
MAX_USER_RX_BUFFER size of data?<br />
For Example:<br />
Client calls libwebsocket_write with a buffer of 4119, of that UserData<br />
is 4097. I see this gets compressed to 206 bytes.<br />
Which the server receives, 206 bytes, but it inflates to 4096 bytes of<br />
user data.<br />
</blockquote>
<br /></div>
For the reception / inflate side, the MAX_USER_RX_BUFFER (this got removed after 1.0, you can set it per-protocol in the protocol struct now) limit only applies to the compressed frame content.<br />
<br />
So your compressed payload of 206 is well below the default limit of 4096.<br />
<br />
The inflated data gets its own malloc'd buffer with a different max size restriction, LWS_MAX_ZLIB_CONN_BUFFER, 64KBytes by default.  So there's no problem dealing with 4097 bytes of data there either.<br />
<br />
That inflated buffer and the length are passed directly then to the user callback untouched.<br />
<br />
I also studied the client send side and couldn't see how that could go wrong either.<div class="im"><br />
<br />
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
libwebsockets_remaining_<u></u>packet_payload tells me no more bytes. But I am<br />
missing 1 byte of data.<br />
</blockquote>
<br /></div>
That's telling you about the compressed data in the actual frame... and indeed the receiving peer had gotten all 206 bytes of that.<br />
<br />
deflate-frame extension should only deliver atomic frames, so there should never be any left over, so 0 is correct from that POV too.<div class="im"><br />
<br />
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The strange thing, if the server goes to close the connection, the<br />
client will write 2 more bytes before the CALLBACK_CLOSED is called.<br />
<br />
Anybody have an idea what is going on here?<br />
</blockquote>
<br /></div>
Those 2 bytes sound like the 2-byte reason code in the CLOSE frame, if that's the case they're not related to your main problem.<br />
<br />
I attach a test patch I used to try to reproduce the problem, I did not find any trouble on HEAD receiving a 4097 byte packet at the server through deflate-frame, when the max normal frame size was set to 4096.<span class="HOEnZb"><font color="#888888"><br />

<br />
-Andy<br />
<br />
</font></span></blockquote></div><br />
</blockquote></div></body></html></body></html>