This adds a new member to the context creation info struct "ws_ping_pong_interval".
If nonzero, it sets the number of seconds that established ws connections are
allowed to be idle before a PING is forced to be sent. If zero (the default) then
tracking of idle connection is disabled for backwards compatibility.
Timeouts cover both the period between decision to send the ping and it being
sent (because it needs the socket to become writeable), and the period between
the ping being sent and the PONG coming back.
INFO debug logs are issues when the timeout stuff is operating.
You can test the server side by running the test server hacked to set ws_ping_pong_interval
and debug log mask of 15. Both the mirror protocol and the server-status protocol are
idle if nothing is happening and will trigger the PING / PONG testing. (You can also
test using lwsws and /etc/lwsws/conf with "ws-pingpong-secs": "20" in the global section)
For client, run the test client with -n -P 20 for 20s interval. -n stops the test client
writing using the mirror protocol, so it will be idle and trigger the PING / PONGs.
The timeout interval may be up to +10s late, as lws checks for affected connections every
10s.
This makes it easy for user code to choose the size of the per-thread
buffer used by various things in lws, including file transfer chunking.
Previously it was 4096, if you leave info.pt_serv_buf_size as zero that
is still the default.
With some caveats, you can increase transfer efficiency by increasing it
to, eg, 128KiB, if that makes sense for your memory situation.
Signed-off-by: Andy Green <andy@warmcat.com>
https://github.com/warmcat/libwebsockets/issues/468
Adds lws_check_opt() to regularize multibit flag checking.
There's a new context creation flag LWS_SERVER_OPTION_DO_SSL_GLOBAL_INIT,
this is included automatically if you give any other SSL-related option flag.
If you give no SSL-related option flag, nor this one directly, then even
though SSL support may be compiled in, it is never initialized nor used for the
whole lifetime of the lws context.
Conversely in order to prepare the context to use SSL, even though, eg, you
are not listening on SSL but will use SSL client connections later, you can
give this flag explicitly to make sure SSL is initialized.
Signed-off-by: Andy Green <andy@warmcat.com>
This adds support for multithreaded service to lws without adding any
threading or locking code in the library.
At context creation time you can request split the service part of the
context into n service domains, which are load-balanced so that the most
idle one gets the next listen socket accept.
There's a single listen socket on one port still.
User code may then spawn n threads doing n service loops / poll()s
simultaneously. Locking is only required (I think) in the existing
FD lock callbacks already handled by the pthreads server example,
and that locking takes place in user code. So the library remains
completely agnostic about the threading / locking scheme.
And by default, it's completely compatible with one service thread
so no changes are required by people uninterested in multithreaded
service.
However for people interested in extremely lightweight mass http[s]/
ws[s] service with minimum provisioning, the library can now do
everything out of the box.
To test it, just try
$ libwebsockets-test-server-pthreads -j 8
where -j controls the number of service threads
Signed-off-by: Andy Green <andy.green@linaro.org>
Considering we go through it once per incoming char, the tests to see if we
should be checking utf-8 are too expensive... move them to a bit that lives
in the wsi and set them once per frame (except for CLOSE who has to update
after the close code has been skipped).
Signed-off-by: Andy Green <andy.green@linaro.org>
Because extensions may use them, we didn't reject on reserved opc or bits set,
just ignored. But the standard does say we should, so now we do.
Signed-off-by: Andy Green <andy.green@linaro.org>
We only supported those specific control packet payloads up to 124.
125 is the correct limit.
Lws was consistent about the wrong limit so there are no other
issues. It doesn't affect user ABI correcting it either.
Signed-off-by: Andy Green <andy.green@linaro.org>
This adds an api lws_close_reason() which lets you control what will
be sent in the close frame when the connection is closed by returning
nonzero from the user callback.
The test server demo is extended to prove it works in both directions.
With this, we should have nice close support.
https://github.com/warmcat/libwebsockets/issues/196
Signed-off-by: Andy Green <andy.green@linaro.org>
- Mainly symbol length reduction
- Whitespace clean
- Code refactor for linear flow
- Audit @Context for API docs vs changes
Signed-off-by: Andy Green <andy.green@linaro.org>
Since struct lws (wsi) now has his own context pointer,
we were able to remove the need for passing context
almost everywhere in the apis.
In turn, that means there's no real use for context being
passed to every callback; in the rare cases context is
needed user code can get it with lws_get_ctx(wsi)
Signed-off-by: Andy Green <andy.green@linaro.org>
Extend the cleanout caused by wsi having a context pointer
into the public api.
There's no point keeping the 1.5 compatibility work,
we have changed the api in several places and
rebuilt wasn't going to be enough a while ago.
Signed-off-by: Andy Green <andy.green@linaro.org>
This nukes all the oldstyle prefixes except in the compatibility code.
struct libwebsockets becomes struct lws too.
The api docs are updated accordingly as are the READMEs that mention
those apis.
Signed-off-by: Andy Green <andy.green@linaro.org>
Between changing to lws_ a few years ago and the previous two
patches migrating the public apis, there are only a few
internal functions left using libwebsocket_*.
Change those to also use lws_ without regard to compatibility
since they were never visible outside the library.
Signed-off-by: Andy Green <andy.green@linaro.org>
Change all internal uses of rationalized public apis to reflect the
new names.
Theer are a few things that got changed as side effect of search/replace
matches, but these are almost all internal. I added a compatibility define
for the public enum that got renamed.
Theoretically existing code should not notice the difference from these
two patches. And new code will find the new names.
https://github.com/warmcat/libwebsockets/issues/357
Signed-off-by: Andy Green <andy.green@linaro.org>
under load, writing packet sizes to the socket that are normally fine
can do partial writes, eg asking to write 4096 may only take 2800 of
it and return 2800 from the actual send.
Until now lws assumed that if it was safe to send, it could take any
size buffer, that's not the case under load.
This patch changes lws_write to return the amount actually taken...
that and the meaning of it becomes tricky when dealing with
compressed links, the amount taken and the amount sent differ. Also
there is no way to recover at the moment from a protocol-encoded
frame only being partially accepted... however for http file send
content it can and does recover now.
Small frames don't have to take any care about it but large atomic
sends (> 2K) have been seen to fail under load.
Signed-off-by: Andy Green <andy.green@linaro.org>
This fixes
http://libwebsockets.org/trac/ticket/13
When using the default rx protocol buffer, the check is
performed against 0 not the default length. That's the
case both in client and server code...
There's no problem if you actually give a max frame size
in the protocol definition.
Signed-off-by: Andy Green <andy.green@linaro.org>
This brings the library sources into compliance with checkpatch
style except for three or four exceptions like WIN32 related stuff
and one long string constant I don't want to break into multiple
sprintf calls.
There should be no functional or compilability change from all
this (hopefully).
Signed-off-by: Andy Green <andy.green@linaro.org>
A new protocol member is defined that controls the size of rx
buffer allocation per connection. For compatibility 0 size
allocates 4096, but you should adapt your protocol definition
array in the user code to declare an appropriate value.
See the changelog for more detail.
The advantage is the rx frame buffer size is now tailored to
what is expected from the protocol, rather than being fixed
to a default of 4096. If your protocol only sends frames of
a dozen bytes this allows you to only allocate an rx frame
buffer of the same size.
For example the per-connection allocation (excluding headers)
for the test server fell from ~4500 to < 750 bytes with this.
Signed-off-by: Andy Green <andy.green@linaro.org>
Large chunks of struct libwebsocket members actually have a mutually
exclusive lifecycle, eg, once the http headers are finished they sit
there unused until the instance is destroyed.
This makes a big improvement in memory efficiency by making four
categories of member: always needed, needed for header processing,
needed for http processing, and needed for ws processing. The last
three are mutually exclusive and bound into a union inside the wsi.
Care needs taking now at "union transitions", although we zeroed down
the struct at init, the other union siblings have been writing the
same memory by the time later member siblings start to use it. So
it must be cleared down appropriately when we cross from one
mutually-exclusive use to another.
Signed-off-by: Andy Green <andy.green@linaro.org>
Since v13 was defined as the released ietf version the older versions
are deprecated. This patch strips out everything to do with the older
versions and gets rid of the option to send stuff unmasked.
The in-tree md5 implementation is then also deleted as nothing needs
it any more, 1280 loc are shed in all
Signed-off-by: Andy Green <andy.green@linaro.org>
The new --without-extensions config flag completely removes all code
and data related to extensions from the build throughout the library
when given.
Signed-off-by: Andy Green <andy.green@linaro.org>
Gregory Junker <ggjunker@gmail.com> noticed the binary flag is not
getting set right, or at all on client side. This should improve
matters.
Signed-off-by: Andy Green <andy.green@linaro.org>
