-
Notifications
You must be signed in to change notification settings - Fork 9.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Socket send timeout #3042
Comments
Could you provide an executable test case? Our tests show that Note that the failure isn’t synchronous. That’s not a thing websockets can do, and if you need synchronous failure you probably want to use HTTP requests instead of websockets. |
I'm facing the same problem, as I upgraded to 3.5.0 in the hope to get working timeouts ;) Maybe I'm wrong, but it looks like the timeouts only cover the reading of frames (I looked at 68c0211). So only the case is detected, where we've started reading a frame and reading further bytes of it time out. What seems missing here is some kind of write timeout, which fires an exception when written bytes are not acknowledged by the other side |
There’s never a positive confirmation that a websocket write was accepted. You need to do that at the application layer. Even if the TCP stack could confirm bytes were consumed by the peer, you really don’t know if they were accepted. For example, the peer might not be your application service; it might just be an HTTP proxy on the client side or a load balancer on the server side. What you do know is that if the websocket’s If you need positive confirmation, use regular HTTP requests which use status codes as receipts. |
@swankjesse Ok, I'm with you, at the end the only reliable way is to implement a health-check on the application layer. Unfortunately I don't know how the browsers do this, but there seems to be a way to detect it. |
We call |
Ah ok. If this is the case, there is either a bug or I still don't understand the implementation. Because simple tests where I've disconnected the network (eg. putting the device in airplane mode) and the client sends messages afterwards, don't lead to a |
Hi guys, after posting this i have read alot about websockets. As i have ready the onFailure will not be called when you try to send a message without internet, because theres no confirmation about the send status of the notification (for me onFailure was never called at all, not for other websockets libs too). Im out of this project now (in which i needed to implement a chat), but i remember that okHttp has a ping/pong feature. The ping/pong is a websocket implematation aspect that says that when a message "ping" is received by the server it must send back a "pong" at the same time, and thats the default way to check if a webserver connection is really working (write "ping" and do a timeout if "pong" was not received soon). |
@th3hamm0r of OkHttp doesn't detect the disconnect then that's a bug. I'll try to confirm. |
Minor note: Sry, to use Android's air plane mode to test the issue was actually only an assumption by me. On a real phone with Android 6 a SSL websocket for example almost instantly fails with an Disconnecting an intermediate node (router, hotspot) from the internet where the client "sends" messages without timeouts still works. |
No obvious action to take on this. |
I've been able to reproduce this on an emulator but the device calls |
I have reproduced that issue on OnePlus One with Android 7.1.2 - onFailure() is not called in airplane mode. |
We have hardware devices, each capable of allowing our app to open a web socket with it. A possible scenario we have to be able to handle is when the device we're connected to is unexpectedly powered down (maybe power outage/unplugged/etc). I've noticed that when we do unplug the device that has an open web socket with our android app, onFailure is never called. While in this state I tested sending data from my android app to the now unpowered device, and that doesn't seem to throw any errors/callbacks either. It gets queued successfully and (I'm guessing) sent successfully (from okhttp's point of view) as the queue size never increases. However as soon as I power up the device again onFailure is immediately called. This happens regardless of how long I wait to plug it back in. 30 seconds or 5 minutes, through out this time the app has no idea its connection is gone until the device has been powered back on. We initialize the client similarly to the above. Because all of these connections are done over local network we have very short time outs. OkHttpClient.Builder() |
@zafrani try OkHttp 3.10. |
Thank you, updating fixed this problem. |
there are some question for me in okhttp 3.10.0,
the network limit at 1kb upload,
the server not Received anything after SOCKET_WRITE_TIMEOUT,the client not call onFailure also, |
@Witype please open a new issue with an executable test case that demonstrates the problem. There are lots of test cases in the test suite to get you started. |
Got stuck on this for awhile. Turns out some Emulator seems to have a problem with onFailure method. |
Hi, i have created a socket connection inside a service using:
Everything works fine, but now i'm trying to simulate a no connection scenario. I have turned on the airplane mode, while in a chat, and tryied to send a message using .send(String). I through that it would fire some kind of exception or the onFailure/onClosed methods, but none of them are called. How can i detect if the .send function really worked? Thanks in advance.
The text was updated successfully, but these errors were encountered: