Add delete, list, show subcommands for tcp inlet and outlet

[lameferret]

> ockam tcp-inlet delete --node <NAME> <INLET_ID> --force(optional)
> ockam tcp-outlet delete --node <NAME> <OUTLET_ID> --force(optional)
> ockam tcp-inlet show <INLET_ID>
> ockam tcp-outlet show <OUTLET_ID>
> ockam tcp-inlet list --node <NAME>
> ockam tcp-outlet list --node <NAME>

Is this structure alright?

Inlet/Outlet Documentation for general understanding

~~I used example/inlet.rs for requirements.~~

~~1. ockam node create n1 -t 127.0.0.1:6001~~ ~~2. ockam node create n2 -t "127.0.0.1:6002~~ ~~- Inlet say a tcp transport, so I create both listener and connection~~ ~~3. ockam tcp-listener create "127.0.0.1:7001" --node n2~~ ~~4. ockam tcp-connection create -t "127.0.0.1:7001" --from n1~~ ~~- route_to_outlet is Route { inner: [1#127.0.0.1:4000, 0#outlet] }~~ ~~5. ockam portal create tcp-inlet 127.0.0.1:6001 127.0.0.1:4000 Error: invalid prefix~~ ~~6. ockam portal create tcp-inlet 127.0.0.1:6001 /ip4/127.0.0.1/tcp/4000 Error: no such node~~ ~~- I tried to create a new node with 127.0.0.1:4000, and it still fails.~~

So, how can I create a portal?

Thanks to #2939

$ ockam node create edge_plane -p 4444
$ ockam transport create -a edge_plane tcp-connector <your personal node address> (not in multiaddr)
$ ockam identity create -a edge_plane
$ ockam secure-channel create -a edge_plane connector /dnsaddr/your-ockam-node/<forwarder-address>/<your-listener-address> (returns secure channel address)
$ ockam portal create -a edge_plane tcp-inlet <bind address and port> /<secure channel address>/<tcp outlet address> 

1. ockam node create n1 -t 127.0.0.1:6001
2. ockam tcp-connection create -t "127.0.0.1:7001" --from n1
3. ockam tcp-listener create "127.0.0.1:7001" --node n1
   • node already has an identity (default)
4. ockam secure-channel create --from n1 --to /ip4/127.0.0.1/tcp/6001/service/api

   /service/d9993bf0ff01d5b62c435acbf5010124

   • Do I need a secure-channel-listener too?
5. • ockam portal create tcp-inlet 127.0.0.1:7001 /ip4/127.0.0.1/tcp/6001/service/api

     No such node available, this is obiously wrong

   • ockam portal create tcp-inlet 127.0.0.1:7001 /service/d9993bf0ff01d5b62c435acbf5010124/127.0.0.1:9000

     Invalid <OUTLET_ADDR>

Looks like I need help with instructions.

[mrinalwadhwa]

@anuvratsingh sorry about taking a few days to reply to this:

Here's a simpler working example of a tcp portal

# create some webserver
> python3 -m http.server --bind 127.0.0.1 5000

# create three ockam nodes
> for i in {1..3}; do ockam node create "n$i" --tcp-listener-address; done

# create a tcp-outlet that points to the address of the target webserver 
> ockam portal create --node n3 blue tcp-outlet 127.0.0.1:5000 'outlet'

# create a tcp-inlet that listens on port 3000 and knows a route to the outlet
> ockam portal create --node n1 tcp-inlet 127.0.0.1:3000 \
    /ip4/127.0.0.1/tcp/6002/ip4/127.0.0.1/tcp/6003/service/outlet

# set a request to the inlet, this request will travel to the outlet
# and then onto the target webserver and you'll get a reply back as though
# the http server was actually at port 3000
curl 127.0.0.1:3000

[lameferret]

Sorry @mrinalwadhwa for being so late, notifications were turned off. I will look into it asap.

[mrinalwadhwa]

Oh no problem at all, thank you for spending time on it!

[lameferret]

Updated instructions.

1. python3 -m http.server --bind 127.0.0.1 5000
2. for i in (seq 1 3); ./target/debug/ockam node create "n$i" --tcp-listener-address "127.0.0.1:600$i"; end
3. ./target/debug/ockam tcp-outlet create --at n3 --from blue --to 127.0.0.1:5000
4. ./target/debug/ockam tcp-inlet create --at n1 --from 127.0.0.1:3000 --to /ip4/127.0.0.1/tcp/6002/ip4/127.0.0.1/tcp/ 6003/service/blue
5. curl 127.0.0.1:3000

[mrinalwadhwa]

@anuvratsingh This now works too.

python3 -m http.server --bind 127.0.0.1 5000

for i in {1..3}; do ockam node create "n$i"; done

ockam tcp-outlet create --at /node/n3 --from /service/outlet --to 127.0.0.1:5000
ockam tcp-inlet create --at /node/n1 --from 127.0.0.1:6000 --to /node/n2/node/n3/service/outlet

curl 127.0.0.1:6000

[lameferret]

Hey @mrinalwadhwa, how should I submit PR, for add inlet/outlet to registry, inlet/outlet show, and similar smaller issues.

1. One PR with multiple commits, which can individually be merged into main.
2. Multiple PRs

[mrinalwadhwa]

I PR with multiple commits would be great 👍

[mrinalwadhwa]

Multiple smaller PRs are faster to land - so either way is okay.

[lameferret]

Sorry, but can I get some help with option 2: Multiple smaller PR's

• Let's say in PR1 I add inlet and outlet to registry, and I push this branch

• Then in PR2 I want to use the things I did in PR1, so what would I do

  • If I create a PR2 branch with PR1 as base, wouldn't this mess thing up when pushing (some rebase issues)?.
  • I have to wait for PR1 to merge to prod (develop) and then work on PR2.
  • Or I can keep using the same branch locally, but push commits to a new branch each time.
    • I'm not sure whether this would work, your input will be really helpful.

[mrinalwadhwa]

Happy to answer such questions so keep them coming.

My workflow in that situation would be to create two branches. feat1 branch is based on develop. feat2 branch is based on feat1 branch. When ready create two PRs - one for each feature. In PR2's comment mention that it is stacked on PR1.

Now someone starts reviewing PR1 and gives some suggestions to fix. When you fix and change feat1, you also rebase the feat2 and push to both.

Once feat1 lands in develop and CI rebases feat2 to develop ... PR2 branch will only have changes relevant to that feature.

If the two features are touching different areas of code. This works pretty well .. you can also let feat2 lag without making any changes to it. If the two are touching similar areas of code then its better to just make them one PR.

[adrianbenavides]

Done