rust-socketio: Performance degradation using SSL

When connecting with HTTPS to a Flask SocketIO server I’m seeing a slowdown of 20 seconds waiting for a response compared to http.

This is happening with header auth and with certificate auth.

let socket = SocketBuilder::new("https://$IP$".to_string())
        .opening_header(
            "Authorization",
            settings.header_auth_value.as_str()
        )
        .on("open", connect_callback)
        .on("submit", submit_callback)
        .on("error", |err, _| {
            warn!("Server Connection Error: {:#?}", err)
        })
        .on("error", |err, _| eprintln!("Error: {:#?}", err))
        // .transport_type(TransportType::WebsocketUpgrade)
        //  .tls_config(tls_connector)
        .connect();

I can see in the nginx logs that the websocket upgrade is switching protocols

client GET /socket.io/?EIO=4&sid=n4wlLsEmzjqGaiGHAAAG&transport=websocket HTTP/1.1 101 45

Any ideas on what could be going wrong?

PS. Not seeing this degradation with python socket io client

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 19 (8 by maintainers)

Most upvoted comments

Ok, that’s unfortunate. Could you try 43bed7db9f1a87162cbc741b642ed8c7f107873c , I reverted it.

1c3t3a on Dec 15, 2021

I prepared a really hotfixy hotfix just to proof my point, if you like you can add the rust-socketio dependency as follows:

rust_socketio = { git = "https://github.com/1c3t3a/rust-socketio", branch = "issue-133"}

It runs in my development environment, would be interesting to know if this also holds true for your environment.

1c3t3a on Dec 1, 2021

Ah great, thanks for the detailed information! I think I tracked down the issue, and 20 seconds makes total sense in that context. Without splitting, the same connection for sending and receiving is used, but receiving is a blocking operation: https://github.com/1c3t3a/rust-socketio/blob/c49fe9e0d6d45a6a803a527c29d949d4874cf3c0/engineio/src/transports/websocket_secure.rs#L99-L104

After the connection is established, the client starts to wait for a message from the server by calling the blocking receive message. At the same time, in another thread (the main one by “managed” by the user) the send method is called and starts to wait for the lock. So now we’re in a deadlock situation, that only gets resolved after 20 seconds, the servers ping interval! Then the lock gets dropped and the client can send.

If I am right the interval should get shorter with a shorter ping interval in the server configuration. Does this make sense @nshaaban-cPacket?

Sorry for the inconvenience, this looks like a logical error!

1c3t3a on Dec 1, 2021