Skip to content
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

Can't proxy custom host/port combination if port conflicts with existing port #6

Closed
itamarst opened this issue Mar 3, 2017 · 0 comments
Labels
t:bug Something isn't working

Comments

@itamarst
Copy link

itamarst commented Mar 3, 2017

Let's say you want to connect to two cloud PostgreSQL databases via Telepresence, so you do:

telepresence --proxy mydb1.cloud:5432 --proxy mydb2.cloud:5432 myservice

This will fail because at the moment 5432 can only be proxied once. This limitation should be removed.

@itamarst itamarst added the t:bug Something isn't working label Mar 3, 2017
@itamarst itamarst changed the title Can't proxy custom host/port combination if port conflicts with existing port Can't proxy custom host/port combination if port conflicts with existing port; also, hard-coded ports don't work with --docker-run Mar 27, 2017
@itamarst itamarst changed the title Can't proxy custom host/port combination if port conflicts with existing port; also, hard-coded ports don't work with --docker-run Can't proxy custom host/port combination if port conflicts with existing port Mar 27, 2017
thallgren added a commit that referenced this issue Sep 7, 2021
A tunnel is closed by one of six things happening at either end (or at
both ends).

1. Read from local connection fails (typically EOF)
2. Write to local connection fails (connection peer closed)
3. Idle timer timed out.
4. Context is cancelled.
5. Disconnect request received from Tunnel peer.
6. DisconnectOK received from Tunnel peer.

When #1 or #2 happens, the Tunnel will send a Disconnect request to
its Tunnel peer, shorten the Idle timer, and then continue to serve
incoming data from the Tunnel peer until a DisconnectOK is received.
Once that happens, it's guaranteed that the Tunnel peer will send no
more messages and the Tunnel is closed.

When #3, #4, or #5 happens, the Tunnel will send a DisconnectOK to its
Tunnel peer and close.

When #6 happens, the Tunnel will simply close.

Signed-off-by: Thomas Hallgren <thomas@datawire.io>
thallgren added a commit that referenced this issue Sep 7, 2021
A tunnel is closed by one of six things happening at either end (or at
both ends).

1. Read from local connection fails (typically EOF)
2. Write to local connection fails (connection peer closed)
3. Idle timer timed out.
4. Context is cancelled.
5. Disconnect request received from Tunnel peer.
6. DisconnectOK received from Tunnel peer.

When #1 or #2 happens, the Tunnel will send a Disconnect request to
its Tunnel peer, shorten the Idle timer, and then continue to serve
incoming data from the Tunnel peer until a DisconnectOK is received.
Once that happens, it's guaranteed that the Tunnel peer will send no
more messages and the Tunnel is closed.

When #3, #4, or #5 happens, the Tunnel will send a DisconnectOK to its
Tunnel peer and close.

When #6 happens, the Tunnel will simply close.

Signed-off-by: Thomas Hallgren <thomas@datawire.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
t:bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant