-
Notifications
You must be signed in to change notification settings - Fork 12
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
[RSDK-9244] [RSDK-9245] Feature gate local signaling and adjust max connections #362
[RSDK-9244] [RSDK-9245] Feature gate local signaling and adjust max connections #362
Conversation
@@ -4,6 +4,7 @@ CONFIG_ESP32_DEFAULT_CPU_FREQ_240=y | |||
CONFIG_ESP_SYSTEM_EVENT_TASK_STACK_SIZE=4096 | |||
CONFIG_PTHREAD_TASK_STACK_SIZE_DEFAULT=8192 | |||
CONFIG_ESP_TLS_SERVER=y | |||
CONFIG_LWIP_MAX_SOCKETS=13 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that we have a fix for https://viam.atlassian.net/browse/RSDK-9213 in via #355, I'm more comfortable bumping this up a little bit. Arguably, we can have more sockets now since you may have both local WebRTC and app brokered running simultaneously.
} else { | ||
3 | ||
} | ||
#[cfg(target_os = "espidf")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Logic to determine the number of max conns was present everywhere that led to instantiating a ViamServerBuilder
, and was slightly different everywhere. I've opted to consolidate the logic inside ViamServerBuilder
and let it decide the default. Explicit calls to with_max_concurrent_connection
are no longer required to raise the default above one.
@@ -15,7 +15,7 @@ links = "micro_rdk" | |||
crate-type = ["lib"] | |||
|
|||
[features] | |||
default = ["builtin-components", "data"] | |||
default = ["builtin-components", "data", "local-signaling"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a default-enabled feature gate for local-signaling
so it is easier to disable if we need.
@@ -194,6 +194,33 @@ where | |||
<Storage as RobotConfigurationStorage>::Error: Debug, | |||
ServerError: From<<Storage as RobotConfigurationStorage>::Error>, | |||
{ | |||
|
|||
pub fn get_default_max_concurrent_connections() -> usize { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is now where we compute the default max number of concurrent connections.
@@ -145,6 +145,7 @@ where | |||
} | |||
|
|||
// TODO(RSDK-9242): Use the builder pattern instead. | |||
#[allow(dead_code)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I opted not to attempt to actually avoid compiling the local signaling support when the local-signaling
feature was off, because it got really messy with the Either
type over the app signaling vs local signaling. I doubt the code savings are significant. If anyone thinks it would be worth it, I'm happy to file a ticket for sometime down the road to attempt it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does this mean we can't complie if local-signaling
flag is disabled?
This feels like a weird state to leave things in, and I personally think we should not have a flag for local signaling anyway. If anything, we can have an env var to check if local signaling is disabled and adds/removes it in the builder step.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, this is exactly so we can compile / clippy when the local-signaling
flag is disabled. Otherwise we get warnings here that register_signaling_server
is unused.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
gotcha, thanks for clarifying.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, just some questions.
max += 2; | ||
} | ||
|
||
// But on an esp32 lacking SPIRAM, assume only one connection can be realized |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the behavior of an SDK trying to connect if local signaling is enabled but lacking spiram (when max connections is 1)?
might be good to have a log message or something to give the user a heads-up about the limitation.
log::warn!("this device can only support one connection at a time blah blah blah");
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, actually, you've caught something that I intended to do, but then forgot to execute on. My intention was that if max conns is too small, to disable local signaling, with a warning.
I will add logic for that and post an update.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mattjperez - Fixed this in latest.
@@ -205,7 +232,7 @@ where | |||
http2_server_port: 12346, | |||
http2_server_insecure: false, | |||
app_client_tasks: Default::default(), | |||
max_concurrent_connections: 1, | |||
max_concurrent_connections: Self::get_default_max_concurrent_connections(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice
@@ -145,6 +145,7 @@ where | |||
} | |||
|
|||
// TODO(RSDK-9242): Use the builder pattern instead. | |||
#[allow(dead_code)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does this mean we can't complie if local-signaling
flag is disabled?
This feels like a weird state to leave things in, and I personally think we should not have a flag for local signaling anyway. If anything, we can have an env var to check if local signaling is disabled and adds/removes it in the builder step.
@@ -145,6 +145,7 @@ where | |||
} | |||
|
|||
// TODO(RSDK-9242): Use the builder pattern instead. | |||
#[allow(dead_code)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, this is exactly so we can compile / clippy when the local-signaling
flag is disabled. Otherwise we get warnings here that register_signaling_server
is unused.
max += 2; | ||
} | ||
|
||
// But on an esp32 lacking SPIRAM, assume only one connection can be realized |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, actually, you've caught something that I intended to do, but then forgot to execute on. My intention was that if max conns is too small, to disable local signaling, with a warning.
I will add logic for that and post an update.
), | ||
robot_config: &config, | ||
local_signaling_server: Arc::new(SignalingServer::new( | ||
#[cfg(feature = "local-signaling")] | ||
local_signaling_server: Some(Arc::new(SignalingServer::new( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mattjperez - Here is where we should decide to not instantiate the SignalingServer
if the max conns is too low.
micro-rdk/src/common/conn/viam.rs
Outdated
let ss = self | ||
.local_signaling_server | ||
.clone() | ||
.filter(|_| self.incomming_connection_manager.max_connections() >= 5); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that's pretty cool, forgot options can use filter
. this way the max_connections()
check only happens if self.local_signaling_server.is_some()
.
My instinct would have been to go with this
let ss = if self.incomming_connection_manager.max_connections() >= 5 {
self.local_signaling_server.clone()
} else {
None
}
Did you still want to add the warning?
It's fine if not though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hah. I actually did have the warning, and then dropped it out after testing. I'll add it back before merging.
See notes inline for more details on each change.