Arne Goedeke wrote: >On 10/18/16 11:46, Stephen R. van den Berg wrote: >> Arne Goedeke wrote: >>> * permessage-deflate is activated by default. i don't believe that >>> this is a good choice.
>> The default is what should help most users. I think it would have, but >> it's not a big deal. >My applications for websockets usually focus on binary data. I usually >care more about latency and CPU than bandwidth and the payload does not >compress well. This is probably different for situations which involve >text. I don't know what other people do. Well, I cater/catered for that. I.e. binary frames are mostly not compressed, even if compression is on. Text frames are mostly compressed. I tried to make it adapt favourably to most real-life conditions, including yours. >I would propose the following: Let's wait until this extension support >has become more stable and then decide which of the "extensions" make >sense as a default (defragment is probably helpful too in most situations). Sounds reasonable. Yes, defragment should have been in there from the get-go. I was surprised it wasn't in the 8.0 interface. It doesn't really offer any advantage on the application level to assemble the fragments yourself. >I just extended the extension support to client mode connections. That >seems to work fine so far. The client does not currently offer any of >the extension parameters during handshake. >* fail connections with invalid parameters >* implement fallback (clients can offer several combinations of > parameters and a server is supposed to pick the first that works) Yes, I know. That's the reason I skipped that, because doing the client was more work than the server side. -- Stephen.
