-
Notifications
You must be signed in to change notification settings - Fork 5
Remove dest_channel_id
from NetworkChannel
#117
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
Conversation
Memory usage after merging this PR will be: Memory Reportaction_microstep_test_c
action_overwrite_test_c
action_test_c
delayed_conn_test_c
empty_action_test_c
event_payload_pool_test_c
event_queue_test_c
multiple_startup_shutdown_test_c
nanopb_test_c
physical_action_test_c
port_test_c
reaction_queue_test_c
request_shutdown_test_c
shutdown_test_c
startup_test_c
tcp_channel_test_c
timer_test_c
|
@@ -486,6 +496,8 @@ void TcpIpChannel_ctor(TcpIpChannel *self, const char *host, unsigned short port | |||
self->fd = 0; | |||
self->state = NETWORK_CHANNEL_STATE_UNINITIALIZED; | |||
|
|||
self->super.get_dest_channel_id = TcpIpChannel_get_dest_channel_id; | |||
self->super.get_connection_state = TcpIpChannel_get_connection_state; |
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.
It seems the connection_state
mapping was missing so I secretly added it here also 😈 hehe
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.
Ops! Thanks!
src/platform/posix/tcp_ip_channel.c
Outdated
} else { | ||
return self->fd; | ||
} | ||
} |
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 might be surprising because we were always talking about identifying TcpIpChannels using ports
.
The issue here is that from the server perspective that is really easy. We have a port that we listen to per channel to each other federate. So we can just use our local listening port to identify messages between federates.
From the client side it is different. When we make a connection the operating system assigns a random port that is managed by the OS and could be retrieved using a POSIX API call by passing t he file descriptor
.
File descriptors though do already exist for client and server side connections and are unique.
So using them seems an easy enough solution for now.
Please give feedback if you think that makes sense or not :)
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 depends on how get_dest_channel_id
is to be used by the runtime. In fact, I think it might not be used by the runtime at all, only by the lower levels of the NetworkChannel implementation. This suggests that it might not be the right decision to have this function as part of the generic NetworkChannel API, rather it some bookkeeping that must be done in the different concrete implementations?
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.
Looks good, but curios if we should have channel_id as part of the NetworkChannel abstraction at all...
@@ -486,6 +496,8 @@ void TcpIpChannel_ctor(TcpIpChannel *self, const char *host, unsigned short port | |||
self->fd = 0; | |||
self->state = NETWORK_CHANNEL_STATE_UNINITIALIZED; | |||
|
|||
self->super.get_dest_channel_id = TcpIpChannel_get_dest_channel_id; | |||
self->super.get_connection_state = TcpIpChannel_get_connection_state; |
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.
Ops! Thanks!
250a9f8
to
9921044
Compare
Memory usage after merging this PR will be: Memory Reportaction_microstep_test_c
action_overwrite_test_c
action_test_c
delayed_conn_test_c
empty_action_test_c
event_payload_pool_test_c
event_queue_test_c
multiple_startup_shutdown_test_c
nanopb_test_c
physical_action_test_c
port_test_c
reaction_queue_test_c
request_shutdown_test_c
shutdown_test_c
startup_test_c
tcp_channel_test_c
timer_test_c
|
Okay I rebased this and removed the The other small change is that I renamed the |
dest_channel_id
from NetworkChannel
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.
Great!
I think it is more reasonable to not duplicate this value if we anyways for example have the ports or file descriptors stored in the concrete channel implementation structs.