As spotted by JM on Trac#40
http://libwebsockets.org/trac/libwebsockets/ticket/40
client connect didn't do anything about being truly nonblocking. This patch
should hopefully solve that.
Signed-off-by: Andy Green <andy.green@linaro.org>
''...Websocket servers return failure responses other than HTTP Status 101 in the case of
mismatches of WebSocket version or additional header data etc...
It seems that libwebsockets shows "WARN: problems parsing header" error in such cases without
calling any callbacks or returning error code. Is this right?
I modified lib/client.c to handle this.''
Signed-off-by: Fujii Bunichiroh <Bunichiroh.Fujii@jp.sony.com>
This tells the OS to reserve a TX buffer at least the size of the biggest RX frame
expected, for both server and client connections.
In Linux, the OS reserves 2 x the requested amount.
This is aimed at reducing the partial large atomic frame send problem to the point
it's only coming at large atomic frames the OS balks at reserving the size for.
If you have a lot of data to send, it is better to split it into multiple writes,
and use the FIN / CONTINUATION websocket stuff to manage it.
See the "fraggle" test app for example code of how to do that.
Signed-off-by: Andy Green <andy.green@linaro.org>
This should get rid of a valgrind uninitialized report when using extpoll,
and gives a new way to share the poll loop with external sockets.
If a pollfd says it has something, you can just pass it to
libwebsocket_serice_fd() whether it is a socket handled by lws or not.
If it sees it is a lws socket, the traffic will be handled and
pollfd->revents will be zeroed now.
If the socket is foreign to lws, it leaves revents alone. So you can see
if you should service by checking the pollfd revents after letting
lws try to service it.
Signed-off-by: Andy Green <andy.green@linaro.org>
close() from javascript api in Chrome and Firefox doesn't do the
right thing. It's because the payload is zero-length (with a frame
key...) This fixes it.
Reported-by: 巫书轶
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>
More flexible this way... NULL for the new member means use
the ssl library default set of ciphers, so as long as your info
struct is zerod by bss or memset, you don't need to do anything
about this change unless you want to set the cipher list.
Signed-off-by: Andy Green <andy.green@linaro.org>
While looking at http://libwebsockets.org/trac/ticket/18
noticed the flow for timeout in service_fd will do bad things
if the fd we came to service has timed out. It gets freed and
then "serviced'.
Reported-by: Joakim Soderberg <joakim.soderberg@gmail.com>
Signed-off-by: Andy Green <andy.green@linaro.org>
The function has a logical problem when the size of the requested
allocation is 0, it will return NULL which is overloaded as
failure.
Actually the whole function is evil as an api, this patch moves
it out of the public API space and fixes it to return 0 for
success or 1 for fail. Private code does not need to to return
wsi->user_space and public code should only get that from the
callback as discussed on trac recently.
Thanks to Edwin for debugging the problem.
Reported-by: Edwin van den Oetelaar <oetelaar.automatisering@gmail.com>
Signed-off-by: Andy Green <andy.green@linaro.org>
