Context could be NULL only if context creation failed in the first
place and user error path is bad... no network connectivity at that
point...
Signed-off-by: Andy Green <andy.green@linaro.org>
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>
In the case we have a lot of connections, checking them all for timeout state
once a second becomes burdensome. At the moment if you have 100K connections,
once a second they all get checked for timeout in a loop.
This patch adds a doubly-linked list based in the context to each wsi, and
only wsi with pending timeouts appear on it. At checking time, we traverse
the list, which costs nothing if empty because nobody has a pending timeout.
Similarly adding and removing from the list costs almost nothing since no
iteration is required no matter how big the list.
The extra 8 or 16 bytes in the wsi are offset a little bit by demoting .pps
from int to char (save 3 bytes). And trim max act exts to 2, since we only
provide one, saving 8 /16 bytes by itself if exts enabled.
Signed-off-by: Andy Green <andy.green@linaro.org>
This adds redirect support to the client side. Lws will follow
server redirects (301) up to three deep.
Signed-off-by: Andy Green <andy.green@linaro.org>
In most cases the close api will see it should send the CCE because
we are still in the waiting server reply state until the end of the
interpretation. Only if we completed the interpretation and moved
on to ESTABLISHED do we need to handle sending it ourselves.
Signed-off-by: Andy Green <andy.green@linaro.org>
After "rerelease"
https://github.com/warmcat/libwebsockets/issues/392#issuecomment-170003294
Since we introduced partial buffering a long while ago,
user code shold never see partial sends and very few
user callbsck attempt to deal with them.
Let's just eliminate the whole concept of user callback
partial send handling under any circumstances.
Signed-off-by: Andy Green <andy.green@linaro.org>
Remove declarations of callback and extension_callback as these are
functions declared in header but not defined anywhere.
Also rename typedefs callback_function and extension_callback_function
to lws_callback_function and lws_extension_callback_function so all
symbolx exported by header have lws prefix;
Signed-off-by: Denis Osvald <denis.osvald@sartura.hr>
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>
Server side has had immediate RX flow control for quite a while.
But client side made do with RX continuing until what had been received was exhausted.
For what Autobahn tests, that's not enough.
This patch gives clientside RX flow control the same immediate effect as the server
side enjoys, re-using the same code.
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>
If the final message fragment contains a payload that has to be
handled in multiple RX callbacks, until now we reported the ws
fragment header FIN state in lws_is_final_fragment().
That was correct, but it's kind of not useful to hear that the
intermediate bufferloads are "final". So now we delay
reporting the logical ws fragment FIN until the final part of
his payload is delivered.
This gets us Autobahn 1.1.6 working.
Signed-off-by: Andy Green <andy.green@linaro.org>
Again we treat user code sending zero length things as a bug in user code.
But Autobahn insists to be able to do it, so now we allow it.
That buys us a pass on Autobahn test 1.1.1 (the first of a bazillion)
Reproduce with
libwebsockets-test-echo --client localhost --port 9001 -u "/runCase?case=1&agent=libwebsockets" -v -d 65535 -n 1
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>
The only guy who cared about this for a long while
(since I eliminated the pre-standard protocol variants)
was sending a close frame.
- Set it to 0 so old code remains happy. It only affects
user code buffer commit, if there's overcommit no harm
done so no effect directly on user ABI.
- Remove all uses inside the library. The sample apps
don't have it any more and that's the recommendation now.
Signed-off-by: Andy Green <andy.green@linaro.org>
