{"action":"closed","issue":{"url":"https://api.github.com/repos/square/okhttp/issues/1925","labels_url":"https://api.github.com/repos/square/okhttp/issues/1925/labels{/name}","comments_url":"https://api.github.com/repos/square/okhttp/issues/1925/comments","events_url":"https://api.github.com/repos/square/okhttp/issues/1925/events","html_url":"https://github.com/square/okhttp/issues/1925","id":111423858,"number":1925,"title":"Socket SO_SNDBUF size too big for some networks","user":{"login":"pwerry","id":858772,"avatar_url":"https://avatars.githubusercontent.com/u/858772?v=3","gravatar_id":"","url":"https://api.github.com/users/pwerry","html_url":"https://github.com/pwerry","followers_url":"https://api.github.com/users/pwerry/followers","following_url":"https://api.github.com/users/pwerry/following{/other_user}","gists_url":"https://api.github.com/users/pwerry/gists{/gist_id}","starred_url":"https://api.github.com/users/pwerry/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pwerry/subscriptions","organizations_url":"https://api.github.com/users/pwerry/orgs","repos_url":"https://api.github.com/users/pwerry/repos","events_url":"https://api.github.com/users/pwerry/events{/privacy}","received_events_url":"https://api.github.com/users/pwerry/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/square/okhttp/labels/bug","name":"bug","color":"fc2929"}],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":8,"created_at":"2015-10-14T15:31:01Z","updated_at":"2016-01-01T22:53:04Z","closed_at":"2016-01-01T22:53:04Z","body":"We've discovered a puzzling issue with `WebSockets` (and perhaps `Sockets` in general) on Android. Under certain circumstances that are not fully understood, writing a large buffer to a `Socket` with a `SO_SNDBUF` size greater than the MTU of the node directly upstream of the device *may* result in that upstream node dropping packets. If you write chunks to the `Socket` in sizes less than the upstream MTU it's not a problem. Our working theory is that the OS is unable to resolve the MTU using PMTUD, even though the router is correctly returning \"fragmentation required\" responses when the DF bit is set (we tested a few ICMP packets to the router). Flushing the underlying `OutputStream` associated with the `Socket` after writing each `Segment` doesn't seem to accomplish much if the total bytes written across all segments is larger than the MTU. The only solution we've been able to find so far is to call `Socket#setSendBufferSize(int)` with a value less than the MTU (1024 seemed reasonable given that the upstream MTU in our case was 1492). \r\n\r\nA few caveats and interesting data points:\r\n- Not all upstream nodes behave this way. In fact we have only been able to reliably replicate the issue using a certain router on a certain network\r\n- A router involved in replicating the issue actually did send back packet fragmentation errors when hit with ICMP DF packets\r\n- The standard MTU on Android is 1500, the standard `SO_SNDBUF` size is 512KB\r\n- Android always seems to report an MTU of 1500 even when the upstream MTU is smaller\r\n- The frequency of this issue in the wild is statistically significant, at approximately 10% of all users. It is especially prevalent in emerging markets like Nigeria, Ghana, and India. \r\n- We can confirm this affects devices running Lollipop, and we estimate it affects devices running KitKat as well. Marshmallow hasn't been tested yet\r\n- It affects a wide range of devices across many manufacturers, implying the issue is probably not manufacturer specific\r\n- This seems to be a problem with the OS rather than with okhttp, but there might be something okhttp can do to reduce the impact of the issue\r\n\r\nJust to test the waters, what appetite would there be for adding an API to `OkHttpClient` to expose a configurable `SO_SNDBUF` size?"}}