diff --git a/changelog b/changelog index 2ab975bc..05880533 100644 --- a/changelog +++ b/changelog @@ -33,7 +33,10 @@ the peak allocation. Setting max_http_header_pool to 1 is fine it will just queue incoming connections before the accept as necessary, you can still have as many -simultaneous post-header connections as you like. +simultaneous post-header connections as you like. Since the http header +processing is completed and the allocation released after ESTABLISHED or the +HTTP callback, even with a pool of 1 many connections can be handled rapidly. + User api changes ---------------- @@ -41,9 +44,9 @@ User api changes 1) LWS_SEND_BUFFER_POST_PADDING is now 0 and deprecated. You can remove it; if you still use it, obviously it does nothing. Old binary code with nonzero LWS_SEND_BUFFER_POST_PADDING is perfectly compatible, the old code just -allocated a buffer bigger than needed. +allocated a buffer bigger than the library is going to use. -The example apps no longer user it. +The example apps no longer use LWS_SEND_BUFFER_POST_PADDING. The only path who made use of it was sending with LWS_WRITE_CLOSE. diff --git a/lib/libwebsockets.h b/lib/libwebsockets.h index f4761e96..807087d1 100644 --- a/lib/libwebsockets.h +++ b/lib/libwebsockets.h @@ -32,8 +32,6 @@ #include "sal-stack-lwip/lwipv4_init.h" namespace { - const int SERVER_PORT = 80; - const int BUFFER_SIZE = 4096; } using namespace mbed::Sockets::v0; @@ -64,7 +62,6 @@ public: public: struct lws *wsi; - char buffer[BUFFER_SIZE]; char writeable; char awaiting_on_writeable; };