feat(elixir): udp hole punching example #6588
Conversation
There was a problem hiding this comment.
Thanks a lot for this example @ckhrysze , I think it's going on the right direction.
Let a couple of comments/questions on it,
Seems we broke the elixir' code in a recent commit, If you have trouble compiling/running your example, cherry-pick this #6634 into your branch (or just rebase on current develop as that's going to be merged soon)
If you have any questions or need some guidance, please don't hesitate to ask
| {:ok, _rendezvous} = | ||
| RendezvousWorker.create( | ||
| address: "rendezvous", | ||
| attributes: %{addresses: %{}, pending_connections: []} |
There was a problem hiding this comment.
do it make sense to pass something other than the empty map and empty list here?, this looks more like an implementation' detail of the Rendezvous Worker, that the client code don't need to be aware of
| @rendezvous_node "rendezvous" | ||
|
|
||
| @impl true | ||
| def handle_call(:ping_rendezvous_server, _, state) do |
There was a problem hiding this comment.
I'm not sure to understand what's the purpose of this initial :ping here. What would be different if the first ping-pong is removed and the state machine starts by the "my address" message?
There was a problem hiding this comment.
Functionally nothing, it was mostly just how I started. Terseness in examples isn't obviously better in mind so I left it, but I'm happy to remove it leaving the example more focused on what is actually being demonstrated.
| nil -> | ||
| Logger.debug("Target #{target} not found") | ||
| pending = [{source, target} | state.attributes.pending_connections] | ||
| put_in(state, [:attributes, :pending_connections], pending) |
There was a problem hiding this comment.
I understand the intention is to let unmatched connection request on the :pending_connections list, but that is never used latter on, there is some missing there.
|
|
||
| Ockam.Node.whereis(my_name) | ||
| |> GenServer.call(:ping_rendezvous_server) | ||
|
|
There was a problem hiding this comment.
I'd have expected here to send a msg to the other end, and wait till receiving a message from the other end as well, to show how user code can make use of the "Puncher" to send messages traversing NAT. Not necessary like this, but this is what would come to my mind:
# Register this process as worker address "app".
Ockam.Node.register_address("app")
{:ok, puncher_addr} = Puncher.create(...)
# Send a msg to the puncher worker. It will forward it to the other end
# and from there it will be routed to the "app" address on the other' end node..
Ockam.Router.route(%{onward_route: [puncher_addr, "app"], message: "hello", ..})
# Since on this example there is no "client" and "server" but both are 01-puncher.exs instances, the peer will send
# a msg to us as well (the previous command). Receive it and print it.
receive do
msg -> print the msg
end
There was a problem hiding this comment.
I'm glad you brought this one up, I saw that self registration and receive block in other examples, but in practice I've never gone to production with code containing an explicit receive block. As such I just made the worker module (Puncher in this case) handle receiving since its already wired to do so. But as the other examples are more along the lines as yours, I'm curious if that is providing additional benefit that I'm not seeing.
A simple Elixir example demonstrating how UDP hole punching could be done
- Removes extra ping calls - Utilizes the pending connections list - Cleanup
A simple Elixir example demonstrating how UDP hole punching could be done
Current behavior
No Elixir examples using UDP
Proposed changes
Elixir example for UDP hole punching
Checks