Cannot connect, sometimes (WeeChat data not received) about glowing-bear HOT 9 CLOSED

Some updates (personal notes). I'm testing with two consecutive WS transmissions from browser to WeeChat: init message followed by bufinfo message.

• Wireshark always sees those two messages
• WeeChat always sees the first one, sometimes the second one (in which case it replies with the current buffers names and the page displays them)
• WeeChat always sees the second one when Wireshark shows a TCP ACK has been sent by the WeeChat relay server after the first message
• To confirm the previous point, adding a short delay (setTimeout of a few milliseconds) between the two transmissions ensures getting the TCP ACK from WeeChat after the first transmitted message and results in a 100% successful bufinfo message response

The relay receive callback is simply not called when a TCP ACK isn't sent between two messages. Which is weird, since sending more than one message without acknowledgement is perfectly valid in TCP. TCP is designed for this on purpose for improved performance.

To confirm this, we write the following WebSocket echo server in Python:

from twisted.internet import reactor
from autobahn.websocket import WebSocketServerFactory, \
                               WebSocketServerProtocol, \
                               listenWS

class EchoServerProtocol(WebSocketServerProtocol):
    count = 0;
    def onMessage(self, msg, binary):
        print "got msg: " + msg
        self.sendMessage("server: " + msg, binary)


if __name__ == '__main__': 
    factory = WebSocketServerFactory("ws://localhost:9000", debug = False)
    factory.protocol = EchoServerProtocol
    listenWS(factory)
    reactor.run()

and the following browser script:

var ws = new WebSocket("ws://localhost:9000/");
ws.onopen = function(e) {
    for (var x = 0; x < 1000; ++x) {
        ws.send("count: " + x);
    }
};
ws.onmessage = function(e) {
    console.log(e);
};

Now, Wireshark sees big chunks of several messages (many TCP packets with no interleaving ACKs) sent by both peers, but they are all there.

Which leads to think: WeeChat lower relay network layer has issues, because I strongly believe the OS is calling its socket's recv with all the information.

from glowing-bear.

Nice investigation Phil! It'd be great to have an easy reproducible bug for that.
@flashcode suggests to try with /relay raw and/or debug mode, and guesses it happens in the relay_client_recv_cb() function in src/plugins/relay/relay-client.c.

from glowing-bear.

I don't think so because I probed the top of this very callback and it's not even called with the second message, so if WeeChat has a bug, it lies in the underlying framework calling relay_client_recv_cb(). I'll try /relay raw later today.

It's easy enough to reproduce. Try glowing-bear a few times until it doesn't work. Python seems to be slow enough between two socket.sendall() to allow an ACK to be received after the first message every time, so a Python client script always succeeds.

from glowing-bear.

Good news, I'm able to reproduce the problem, with my test page for websocket (thanks @torhve for help to reproduce).
I'll investigate and let you know if I find the bug (which I think is in WeeChat).

from glowing-bear.

Good news indeed! In the meantime, putting all the commands in the same request seems to be an effective workaround so I am closing this specific issue. Thanks @torhve and @flashcode.

from glowing-bear.

I fixed the problem in WeeChat. Please try with latest git version and confirm me if it's OK or not. It's important to test it now, because next release is tomorrow, I hope I didn't break anything with websockets.

from glowing-bear.

So the problem was when many frames were sent in a single message, WeeChat was decoding only the first one. Now there is a loop to decode all frames in a message.

from glowing-bear.

@flashcode: I have tested the git version and can confirm that it works well (without using the "workaround" described here)

from glowing-bear.

Thanks a lot @flashcode. I was just about to investigate the socket's receive part when I saw this. This is very good news.

from glowing-bear.