[Libwebsockets] LWS_CALLBACK_RECEIVE not getting called

Larry Hayes lhayesg at gmail.com
Sat Jan 26 00:38:06 CET 2013


Hello,

Well, I changed my client and the issue went away:

CLIENT:
context = libwebsocket_create_context(CONTEXT_PORT_NO_LISTEN, NULL,
                                //protocols,
libwebsocket_internal_extensions,
                                protocols, NULL,
                                NULL, NULL, NULL, -1, -1, 0, NULL);

I removed the libwebsocket_internal_extensions from the context create and
my server no longer has a problem.


SERVER:
        context_ssl_cert_ = libwebsocket_create_context(wssPort_,
wssAddr_.c_str(), protocols_ssl_cert,

libwebsocket_internal_extensions,
                                                    cert_path.c_str(),
key_path.c_str(), ca_path.c_str(),
                                                    -1, -1,
LWS_SERVER_OPTION_REQUIRE_VALID_OPENSSL_CLIENT_CERT, NULL);


Do you think I need to remove it from the server as well?

  I am not really sure what it does anyway.

Larry

On Fri, Jan 25, 2013 at 5:04 PM, Andy Green <andy at warmcat.com> wrote:

> Hi -
>
> No from the user code everything should be the same with or without ssl.
>
> I'll study this shortly, can you clarify what you're doing when you see
> it? Sending a big (say 128kbyte) frame is enough?
>
> -Andy
>
>
> Larry Hayes <lhayesg at gmail.com> wrote:
>>
>> Hello,
>>
>> Spoke to soon.
>>
>> Using: libwebsockets-1.0-chrome25-firefox17
>>
>> Non-ssl work fine. When messages are larger then 4096, receive gets
>> called multiple times.
>>
>> But when using SSL connection only the first 4096 bytes are read and
>> returned to receive callback  and libwebsockets_remaining_packet_payload is
>> returning 0. So I am only getting a partial message.
>>
>> Trying to verify with tcpdump if entire message is sent across.
>>
>> Is there anything on the Client side that I need to do different between
>> SSL and non SSL writes?
>>
>> Thanks
>>
>> Larry
>>
>> On Fri, Jan 25, 2013 at 3:06 PM, Larry Hayes <lhayesg at gmail.com> wrote:
>>
>>> That was my first change to sync up the two buffers.
>>>
>>> I compiled my server with the v1.0 library.
>>> Kept my client on the older version.
>>> The problem went away.
>>>
>>> I will upgrade my server to use the newer version.
>>>
>>> Thanks
>>>
>>> Larry
>>>
>>>
>>>
>>> On Fri, Jan 25, 2013 at 7:15 AM, "Andy Green (林安廸)" <andy at warmcat.com>wrote:
>>>
>>>> On 25/01/13 06:58, the mail apparently from Larry Hayes included:
>>>>
>>>>  Hello,
>>>>>
>>>>> I am using a slightly older version of libwebsocket:
>>>>> libwebsockets-**71e53691756fd420c409538c71b010**997f06f414
>>>>>
>>>>> Maybe this has been fixed in a later version.
>>>>>
>>>>> Every thing works OK with User Data less than 1994 bytes
>>>>> write mode on the client is set to TEXT.
>>>>> SSL connection.
>>>>>
>>>>> But on the larger messages the Servers receive callback is  not getting
>>>>> called.
>>>>> The libwebsocket_service_fd() is returning 0, but no callback is
>>>>> getting
>>>>> invoked.
>>>>>
>>>>> The rx_packet_length is getting set correctly to 1994
>>>>> It does 2 iteration on the libwebsocket_read().
>>>>> But the second call has eff_buf.token_len = 1
>>>>> While at this point rx_packet_length = 2.
>>>>>
>>>>> If there was a fix for this can someone point me to version that fixed
>>>>> it.
>>>>> I will just patch what I am running with.
>>>>>
>>>>> If not I will try the latest tomorrow.
>>>>>
>>>>> Anyone seen this issue?
>>>>>
>>>>> The client says the write was successful.
>>>>>
>>>>
>>>> Hm I guess this might be about MAX_BROADCAST_PAYLOAD, set in
>>>> lib/private-libwebsockets.h.  In that version it was set to 2048
>>>>
>>>> If you are indeed using broadcasts to send the data, try cranking this
>>>> up to 4096, which is what it is set to in HEAD.
>>>>
>>>> -Andy
>>>>
>>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20130125/69ac2a54/attachment-0001.html>


More information about the Libwebsockets mailing list