Mixing
What is causing multicast messages not to flow immediately after wifi restart
I have an Android app that creates a MulticastSocket, joins a MC group and receives messages from another machine on the local wifi network.
MulticastSocket socket = new MulticastSocket(null); // Create an unbound socket.
socket.setSoTimeout(LISTEN_TIMEOUT_MILLIS);
socket.setReuseAddress(true);
socket.bind(new InetSocketAddress(listenPort)); // Bind to the configured multicast port
final WifiManager.MulticastLock lock = wifiManager.createMulticastLock("my_lock");
lock.acquire();
socket.setNetworkInterface(networkInterface);
socket.joinGroup(multicastGroup);
while (true) {
socket.receive(packet);
// Do something with the packet
// Handle timeout etc.
// Handle change of network interface by leaving group, setting netIntf and joining group again.
}
socket.leaveGroup(multicastGroup);
socket.close();
lock.release();
Works well on most Android devices (Huawei, Samsung), but on some (Pixel3), if the WiFi on the device is switched off and then back on again, while the app sees the Wifi connection come live, it can take up to 14 mins (it is extremely variable) before the MC messages start being received again.
Even throwing away the Socket and creating a fresh MCSocket doesn't alleviate the delay.
But it has to be some state that is held within the JVM, because a restart of the app causes it to connect immediately.
It feels like there is some lease that is being held for the MC connection that is only being renewed on a clock cycle.
So my questions are:
- What is causing the MC messages to not flow immediately after the
WiFi connection comes back up and a new MCSocket is created to
listen to it. - What can I do to ensure timely resumption of the message flow?
android multicast asked Dec 29 '18 at 6:46
WilliamWilliam
16.7k74079
add a comment |
I have an Android app that creates a MulticastSocket, joins a MC group and receives messages from another machine on the local wifi network.
MulticastSocket socket = new MulticastSocket(null); // Create an unbound socket.
socket.setSoTimeout(LISTEN_TIMEOUT_MILLIS);
socket.setReuseAddress(true);
socket.bind(new InetSocketAddress(listenPort)); // Bind to the configured multicast port
final WifiManager.MulticastLock lock = wifiManager.createMulticastLock("my_lock");
lock.acquire();
socket.setNetworkInterface(networkInterface);
socket.joinGroup(multicastGroup);
while (true) {
socket.receive(packet);
// Do something with the packet
// Handle timeout etc.
// Handle change of network interface by leaving group, setting netIntf and joining group again.
}
socket.leaveGroup(multicastGroup);
socket.close();
lock.release();
Works well on most Android devices (Huawei, Samsung), but on some (Pixel3), if the WiFi on the device is switched off and then back on again, while the app sees the Wifi connection come live, it can take up to 14 mins (it is extremely variable) before the MC messages start being received again.
Even throwing away the Socket and creating a fresh MCSocket doesn't alleviate the delay.
But it has to be some state that is held within the JVM, because a restart of the app causes it to connect immediately.
It feels like there is some lease that is being held for the MC connection that is only being renewed on a clock cycle.
So my questions are:
- What is causing the MC messages to not flow immediately after the
WiFi connection comes back up and a new MCSocket is created to
listen to it. - What can I do to ensure timely resumption of the message flow?
android multicast asked Dec 29 '18 at 6:46
WilliamWilliam
16.7k74079
Since this is multicast, are sent packets being received by some clients and not others?
– Wayne Phipps
Jan 1 at 2:57
Yes. The packets are still being sent. Same app running on other Android devices still receive the packets. The only client that stops receiving the packets (for some indeterminate time) is the app running on the Android device that had it's WiFi disabled and then re-enabled (or switched to another WiFi network and back again). It will stop receiving the packets for between 0 and 14 mins.
– William
Jan 1 at 3:50
Try this: WifiManager.MulticastLock
– Kousic
Jan 2 at 6:25
Thanks @Kousic but I am already using the WiFiManager#MulticastLock. Have added it to the code above.
– William
Jan 2 at 7:41
add a comment |
I have an Android app that creates a MulticastSocket, joins a MC group and receives messages from another machine on the local wifi network.
MulticastSocket socket = new MulticastSocket(null); // Create an unbound socket.
socket.setSoTimeout(LISTEN_TIMEOUT_MILLIS);
socket.setReuseAddress(true);
socket.bind(new InetSocketAddress(listenPort)); // Bind to the configured multicast port
final WifiManager.MulticastLock lock = wifiManager.createMulticastLock("my_lock");
lock.acquire();
socket.setNetworkInterface(networkInterface);
socket.joinGroup(multicastGroup);
while (true) {
socket.receive(packet);
// Do something with the packet
// Handle timeout etc.
// Handle change of network interface by leaving group, setting netIntf and joining group again.
}
socket.leaveGroup(multicastGroup);
socket.close();
lock.release();
Works well on most Android devices (Huawei, Samsung), but on some (Pixel3), if the WiFi on the device is switched off and then back on again, while the app sees the Wifi connection come live, it can take up to 14 mins (it is extremely variable) before the MC messages start being received again.
Even throwing away the Socket and creating a fresh MCSocket doesn't alleviate the delay.
But it has to be some state that is held within the JVM, because a restart of the app causes it to connect immediately.
It feels like there is some lease that is being held for the MC connection that is only being renewed on a clock cycle.
So my questions are:
- What is causing the MC messages to not flow immediately after the
WiFi connection comes back up and a new MCSocket is created to
listen to it. - What can I do to ensure timely resumption of the message flow?
android multicast asked Dec 29 '18 at 6:46
WilliamWilliam
16.7k74079
I have an Android app that creates a MulticastSocket, joins a MC group and receives messages from another machine on the local wifi network.
MulticastSocket socket = new MulticastSocket(null); // Create an unbound socket.
socket.setSoTimeout(LISTEN_TIMEOUT_MILLIS);
socket.setReuseAddress(true);
socket.bind(new InetSocketAddress(listenPort)); // Bind to the configured multicast port
final WifiManager.MulticastLock lock = wifiManager.createMulticastLock("my_lock");
lock.acquire();
socket.setNetworkInterface(networkInterface);
socket.joinGroup(multicastGroup);
while (true) {
socket.receive(packet);
// Do something with the packet
// Handle timeout etc.
// Handle change of network interface by leaving group, setting netIntf and joining group again.
}
socket.leaveGroup(multicastGroup);
socket.close();
lock.release();
Works well on most Android devices (Huawei, Samsung), but on some (Pixel3), if the WiFi on the device is switched off and then back on again, while the app sees the Wifi connection come live, it can take up to 14 mins (it is extremely variable) before the MC messages start being received again.
Even throwing away the Socket and creating a fresh MCSocket doesn't alleviate the delay.
But it has to be some state that is held within the JVM, because a restart of the app causes it to connect immediately.
It feels like there is some lease that is being held for the MC connection that is only being renewed on a clock cycle.
So my questions are:
- What is causing the MC messages to not flow immediately after the
WiFi connection comes back up and a new MCSocket is created to
listen to it. - What can I do to ensure timely resumption of the message flow?
android multicast android multicast asked Dec 29 '18 at 6:46
WilliamWilliam
16.7k74079
asked Dec 29 '18 at 6:46
WilliamWilliam
16.7k74079
edited Jan 2 at 7:45
William
asked Dec 29 '18 at 6:46
WilliamWilliam
16.7k74079
asked Dec 29 '18 at 6:46
WilliamWilliam
16.7k74079
asked Dec 29 '18 at 6:46
WilliamWilliam
16.7k74079
16.7k74079
Since this is multicast, are sent packets being received by some clients and not others?
– Wayne Phipps
Jan 1 at 2:57
Yes. The packets are still being sent. Same app running on other Android devices still receive the packets. The only client that stops receiving the packets (for some indeterminate time) is the app running on the Android device that had it's WiFi disabled and then re-enabled (or switched to another WiFi network and back again). It will stop receiving the packets for between 0 and 14 mins.
– William
Jan 1 at 3:50
Try this: WifiManager.MulticastLock
– Kousic
Jan 2 at 6:25
Thanks @Kousic but I am already using the WiFiManager#MulticastLock. Have added it to the code above.
– William
Jan 2 at 7:41
add a comment |
Since this is multicast, are sent packets being received by some clients and not others?
– Wayne Phipps
Jan 1 at 2:57
Yes. The packets are still being sent. Same app running on other Android devices still receive the packets. The only client that stops receiving the packets (for some indeterminate time) is the app running on the Android device that had it's WiFi disabled and then re-enabled (or switched to another WiFi network and back again). It will stop receiving the packets for between 0 and 14 mins.
– William
Jan 1 at 3:50
Try this: WifiManager.MulticastLock
– Kousic
Jan 2 at 6:25
Thanks @Kousic but I am already using the WiFiManager#MulticastLock. Have added it to the code above.
– William
Jan 2 at 7:41
Since this is multicast, are sent packets being received by some clients and not others?
– Wayne Phipps
Jan 1 at 2:57
Since this is multicast, are sent packets being received by some clients and not others?
– Wayne Phipps
Jan 1 at 2:57
Yes. The packets are still being sent. Same app running on other Android devices still receive the packets. The only client that stops receiving the packets (for some indeterminate time) is the app running on the Android device that had it's WiFi disabled and then re-enabled (or switched to another WiFi network and back again). It will stop receiving the packets for between 0 and 14 mins.
– William
Jan 1 at 3:50
Yes. The packets are still being sent. Same app running on other Android devices still receive the packets. The only client that stops receiving the packets (for some indeterminate time) is the app running on the Android device that had it's WiFi disabled and then re-enabled (or switched to another WiFi network and back again). It will stop receiving the packets for between 0 and 14 mins.
– William
Jan 1 at 3:50
Try this: WifiManager.MulticastLock
– Kousic
Jan 2 at 6:25
Try this: WifiManager.MulticastLock
– Kousic
Jan 2 at 6:25
Thanks @Kousic but I am already using the WiFiManager#MulticastLock. Have added it to the code above.
– William
Jan 2 at 7:41
Thanks @Kousic but I am already using the WiFiManager#MulticastLock. Have added it to the code above.
– William
Jan 2 at 7:41
add a comment |
1 Answer
1
active
oldest
votes
I notice you've updated your question to include WifiManager.MulticastLock
I wonder if you are you reacquiring the lock when the Wifi connection comes back, some posts here on SO imply this is necessary.
I note the comment on the following post:
Re: https://stackoverflow.com/a/4002084/1015289
it turns out that your multicast lock is destroyed when the connectivity goes away (the long delay was me rewriting my code three times before I figured this out). So, you have to reacquire the lock every time the connection comes back
answered Jan 2 at 15:06
Wayne PhippsWayne Phipps
1,14342130
1
Thanks, that is one option that I didn't consider. Will test it.
– William
Jan 3 at 21:18
One thing to bare in mind is that the function they mention is deprecated, apps should use the more versatile requestNetwork(NetworkRequest, PendingIntent), registerNetworkCallback(NetworkRequest, PendingIntent) or registerDefaultNetworkCallback(ConnectivityManager.NetworkCallback). That is mentioned in the docs though here: developer.android.com/reference/android/net/…
– Wayne Phipps
Jan 3 at 21:20
1
Thank you - this is the missing piece of the puzzle. I've stressed it for the last 2 hours and the messages always start to flow immediately. Hopefully this saves other Android devs from endless days of pain in what appears to be MC flakiness on Android.
– William
Jan 3 at 23:50
Thanks for posting your question, it was certainly interesting. I'm glad I could help, thank you for the bounty.
– Wayne Phipps
Jan 4 at 8:59
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53967345%2fwhat-is-causing-multicast-messages-not-to-flow-immediately-after-wifi-restart%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I notice you've updated your question to include WifiManager.MulticastLock
I wonder if you are you reacquiring the lock when the Wifi connection comes back, some posts here on SO imply this is necessary.
I note the comment on the following post:
Re: https://stackoverflow.com/a/4002084/1015289
it turns out that your multicast lock is destroyed when the connectivity goes away (the long delay was me rewriting my code three times before I figured this out). So, you have to reacquire the lock every time the connection comes back
answered Jan 2 at 15:06
Wayne PhippsWayne Phipps
1,14342130
1
Thanks, that is one option that I didn't consider. Will test it.
– William
Jan 3 at 21:18
One thing to bare in mind is that the function they mention is deprecated, apps should use the more versatile requestNetwork(NetworkRequest, PendingIntent), registerNetworkCallback(NetworkRequest, PendingIntent) or registerDefaultNetworkCallback(ConnectivityManager.NetworkCallback). That is mentioned in the docs though here: developer.android.com/reference/android/net/…
– Wayne Phipps
Jan 3 at 21:20
1
Thank you - this is the missing piece of the puzzle. I've stressed it for the last 2 hours and the messages always start to flow immediately. Hopefully this saves other Android devs from endless days of pain in what appears to be MC flakiness on Android.
– William
Jan 3 at 23:50
Thanks for posting your question, it was certainly interesting. I'm glad I could help, thank you for the bounty.
– Wayne Phipps
Jan 4 at 8:59
add a comment |
I notice you've updated your question to include WifiManager.MulticastLock
I wonder if you are you reacquiring the lock when the Wifi connection comes back, some posts here on SO imply this is necessary.
I note the comment on the following post:
Re: https://stackoverflow.com/a/4002084/1015289
it turns out that your multicast lock is destroyed when the connectivity goes away (the long delay was me rewriting my code three times before I figured this out). So, you have to reacquire the lock every time the connection comes back
answered Jan 2 at 15:06
Wayne PhippsWayne Phipps
1,14342130
1
Thanks, that is one option that I didn't consider. Will test it.
– William
Jan 3 at 21:18
One thing to bare in mind is that the function they mention is deprecated, apps should use the more versatile requestNetwork(NetworkRequest, PendingIntent), registerNetworkCallback(NetworkRequest, PendingIntent) or registerDefaultNetworkCallback(ConnectivityManager.NetworkCallback). That is mentioned in the docs though here: developer.android.com/reference/android/net/…
– Wayne Phipps
Jan 3 at 21:20
1
Thank you - this is the missing piece of the puzzle. I've stressed it for the last 2 hours and the messages always start to flow immediately. Hopefully this saves other Android devs from endless days of pain in what appears to be MC flakiness on Android.
– William
Jan 3 at 23:50
Thanks for posting your question, it was certainly interesting. I'm glad I could help, thank you for the bounty.
– Wayne Phipps
Jan 4 at 8:59
add a comment |
I notice you've updated your question to include WifiManager.MulticastLock
I wonder if you are you reacquiring the lock when the Wifi connection comes back, some posts here on SO imply this is necessary.
I note the comment on the following post:
Re: https://stackoverflow.com/a/4002084/1015289
it turns out that your multicast lock is destroyed when the connectivity goes away (the long delay was me rewriting my code three times before I figured this out). So, you have to reacquire the lock every time the connection comes back
answered Jan 2 at 15:06
Wayne PhippsWayne Phipps
1,14342130
I notice you've updated your question to include WifiManager.MulticastLock
I wonder if you are you reacquiring the lock when the Wifi connection comes back, some posts here on SO imply this is necessary.
I note the comment on the following post:
Re: https://stackoverflow.com/a/4002084/1015289
it turns out that your multicast lock is destroyed when the connectivity goes away (the long delay was me rewriting my code three times before I figured this out). So, you have to reacquire the lock every time the connection comes back
answered Jan 2 at 15:06
Wayne PhippsWayne Phipps
1,14342130
answered Jan 2 at 15:06
Wayne PhippsWayne Phipps
1,14342130
answered Jan 2 at 15:06
Wayne PhippsWayne Phipps
1,14342130
answered Jan 2 at 15:06
Wayne PhippsWayne Phipps
1,14342130
1,14342130
1
Thanks, that is one option that I didn't consider. Will test it.
– William
Jan 3 at 21:18
One thing to bare in mind is that the function they mention is deprecated, apps should use the more versatile requestNetwork(NetworkRequest, PendingIntent), registerNetworkCallback(NetworkRequest, PendingIntent) or registerDefaultNetworkCallback(ConnectivityManager.NetworkCallback). That is mentioned in the docs though here: developer.android.com/reference/android/net/…
– Wayne Phipps
Jan 3 at 21:20
1
Thank you - this is the missing piece of the puzzle. I've stressed it for the last 2 hours and the messages always start to flow immediately. Hopefully this saves other Android devs from endless days of pain in what appears to be MC flakiness on Android.
– William
Jan 3 at 23:50
Thanks for posting your question, it was certainly interesting. I'm glad I could help, thank you for the bounty.
– Wayne Phipps
Jan 4 at 8:59
add a comment |
1
Thanks, that is one option that I didn't consider. Will test it.
– William
Jan 3 at 21:18
One thing to bare in mind is that the function they mention is deprecated, apps should use the more versatile requestNetwork(NetworkRequest, PendingIntent), registerNetworkCallback(NetworkRequest, PendingIntent) or registerDefaultNetworkCallback(ConnectivityManager.NetworkCallback). That is mentioned in the docs though here: developer.android.com/reference/android/net/…
– Wayne Phipps
Jan 3 at 21:20
1
Thank you - this is the missing piece of the puzzle. I've stressed it for the last 2 hours and the messages always start to flow immediately. Hopefully this saves other Android devs from endless days of pain in what appears to be MC flakiness on Android.
– William
Jan 3 at 23:50
Thanks for posting your question, it was certainly interesting. I'm glad I could help, thank you for the bounty.
– Wayne Phipps
Jan 4 at 8:59
1
1
Thanks, that is one option that I didn't consider. Will test it.
– William
Jan 3 at 21:18
Thanks, that is one option that I didn't consider. Will test it.
– William
Jan 3 at 21:18
One thing to bare in mind is that the function they mention is deprecated, apps should use the more versatile requestNetwork(NetworkRequest, PendingIntent), registerNetworkCallback(NetworkRequest, PendingIntent) or registerDefaultNetworkCallback(ConnectivityManager.NetworkCallback). That is mentioned in the docs though here: developer.android.com/reference/android/net/…
– Wayne Phipps
Jan 3 at 21:20
One thing to bare in mind is that the function they mention is deprecated, apps should use the more versatile requestNetwork(NetworkRequest, PendingIntent), registerNetworkCallback(NetworkRequest, PendingIntent) or registerDefaultNetworkCallback(ConnectivityManager.NetworkCallback). That is mentioned in the docs though here: developer.android.com/reference/android/net/…
– Wayne Phipps
Jan 3 at 21:20
1
1
Thank you - this is the missing piece of the puzzle. I've stressed it for the last 2 hours and the messages always start to flow immediately. Hopefully this saves other Android devs from endless days of pain in what appears to be MC flakiness on Android.
– William
Jan 3 at 23:50
Thank you - this is the missing piece of the puzzle. I've stressed it for the last 2 hours and the messages always start to flow immediately. Hopefully this saves other Android devs from endless days of pain in what appears to be MC flakiness on Android.
– William
Jan 3 at 23:50
Thanks for posting your question, it was certainly interesting. I'm glad I could help, thank you for the bounty.
– Wayne Phipps
Jan 4 at 8:59
Thanks for posting your question, it was certainly interesting. I'm glad I could help, thank you for the bounty.
– Wayne Phipps
Jan 4 at 8:59
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53967345%2fwhat-is-causing-multicast-messages-not-to-flow-immediately-after-wifi-restart%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Since this is multicast, are sent packets being received by some clients and not others?
– Wayne Phipps
Jan 1 at 2:57
Yes. The packets are still being sent. Same app running on other Android devices still receive the packets. The only client that stops receiving the packets (for some indeterminate time) is the app running on the Android device that had it's WiFi disabled and then re-enabled (or switched to another WiFi network and back again). It will stop receiving the packets for between 0 and 14 mins.
– William
Jan 1 at 3:50
Try this: WifiManager.MulticastLock
– Kousic
Jan 2 at 6:25
Thanks @Kousic but I am already using the WiFiManager#MulticastLock. Have added it to the code above.
– William
Jan 2 at 7:41