How to set up a persistent TCP gender-changer proxy?

up vote
9
down vote

favorite

I have a provider (A) that wants to send us data through an incoming TCP connection. Unfortunately the consuming service (B) cannot receive inbound TCP connections. Also it does not have a static IP, another requirement.

One way to solve this would be a service that connects the incoming TCP A port to another TCP port B, so that the consumer can make an outbound connection to B.

This is not a unique problem [1] [2], and with socat I can make something very close to what I want:

socat -d -d -d -u TCP4-LISTEN:PORT-A,reuseaddr TCP4-LISTEN:PORT-B,reuseaddr

However, this has the following problems:

If B disconnects, it cannot re-connect. With TCP4-LISTEN:PORT-B,reuseaddr,fork, it can connect but does not receive data.

B cannot connect before A has established a connection (surmountable)

Only one connection can be established to PORT-B (surmountable)

Is there a way to adjust the command so that is becomes "permament" and resistent to failures?

edited Aug 17 at 16:10

200_success

4,07011739

asked Aug 17 at 11:54

dtech

3811522

add a commentÂ |Â

up vote
9
down vote

favorite

One way to solve this would be a service that connects the incoming TCP A port to another TCP port B, so that the consumer can make an outbound connection to B.

This is not a unique problem [1] [2], and with socat I can make something very close to what I want:

socat -d -d -d -u TCP4-LISTEN:PORT-A,reuseaddr TCP4-LISTEN:PORT-B,reuseaddr

However, this has the following problems:

If B disconnects, it cannot re-connect. With TCP4-LISTEN:PORT-B,reuseaddr,fork, it can connect but does not receive data.

B cannot connect before A has established a connection (surmountable)

Only one connection can be established to PORT-B (surmountable)

Is there a way to adjust the command so that is becomes "permament" and resistent to failures?

edited Aug 17 at 16:10

200_success

4,07011739

asked Aug 17 at 11:54

dtech

3811522

add a commentÂ |Â

up vote
9
down vote

favorite

One way to solve this would be a service that connects the incoming TCP A port to another TCP port B, so that the consumer can make an outbound connection to B.

This is not a unique problem [1] [2], and with socat I can make something very close to what I want:

socat -d -d -d -u TCP4-LISTEN:PORT-A,reuseaddr TCP4-LISTEN:PORT-B,reuseaddr

However, this has the following problems:

If B disconnects, it cannot re-connect. With TCP4-LISTEN:PORT-B,reuseaddr,fork, it can connect but does not receive data.

B cannot connect before A has established a connection (surmountable)

Only one connection can be established to PORT-B (surmountable)

Is there a way to adjust the command so that is becomes "permament" and resistent to failures?

edited Aug 17 at 16:10

200_success

4,07011739

asked Aug 17 at 11:54

dtech

3811522

One way to solve this would be a service that connects the incoming TCP A port to another TCP port B, so that the consumer can make an outbound connection to B.

This is not a unique problem [1] [2], and with socat I can make something very close to what I want:

socat -d -d -d -u TCP4-LISTEN:PORT-A,reuseaddr TCP4-LISTEN:PORT-B,reuseaddr

However, this has the following problems:

If B disconnects, it cannot re-connect. With TCP4-LISTEN:PORT-B,reuseaddr,fork, it can connect but does not receive data.

B cannot connect before A has established a connection (surmountable)

Only one connection can be established to PORT-B (surmountable)

Is there a way to adjust the command so that is becomes "permament" and resistent to failures?

edited Aug 17 at 16:10

200_success

4,07011739

asked Aug 17 at 11:54

dtech

3811522

edited Aug 17 at 16:10

200_success

4,07011739

edited Aug 17 at 16:10

200_success

4,07011739

edited Aug 17 at 16:10

200_success

4,07011739

asked Aug 17 at 11:54

dtech

3811522

asked Aug 17 at 11:54

dtech

3811522

asked Aug 17 at 11:54

dtech

3811522

add a commentÂ |Â

2 Answers
2

active

oldest

votes

up vote
10
down vote

accepted

The important question is, how will A react to loss of connection, or to connection being refused? Anything that just assumes that a single TCP connection will stay up forever is going to be fragile; that's just the nature of internet.

How about setting up the socat as a [x]inetd service?

You would set xinetd to listen in PORT-B, and start the socat -u TCP4-LISTEN:PORT-A,reuseaddr STDIO as soon as the B-side connects.

xinetd will pass the incoming traffic from B-side to standard input of socat, and catch the standard output of socat and pass it to the B-side.

If B disconnects, then the socat process can be allowed to end; xinetd will start a new one as soon as B connects again. While B is disconnected, A will be getting "connection refused" errors.

I once had to do something quite similar on an old HP-UX system.

answered Aug 17 at 12:42

telcoM

2,149513

A will attempt to reconnect on an interval on loss of connection, so that is covered. xinetd seems like it could work. Will try and report back, thanks!
â€“Â dtech
Aug 17 at 13:10

It solves the most important problem: that the services can re-establish connection on failure. Thanks!
â€“Â dtech
Aug 20 at 13:06

add a commentÂ |Â

up vote
3
down vote

The real world is messy.

In the real world sometimes TCP connections die, this may happen for example if a stateful firewall or NAT is rebooted, if the connection goes too long without traffic, if the underlying connection is down for too long.

Furthermore sometimes when connections die they don't die symmetrically. If a connection carrying a lot of data dies then it is likely that the sender will notice that it is dead long before the recipiant does so. This has a couple of side effects.

If the connection is initiated from sender to recipiant then a new connection may come in while the old connection is apparently still alive.

If the connection is initiated from recipiant to sender then there may be a substantial delay between the sender detecting the connection is broken and the recipiant detecting that fact and triggering a reconnection.

Furthermore TCP connections are a stream of bytes, NOT a stream of messages, so when your connection dies you may receive a partial message.

The net result of this leads me to conclude that a robust solution requires an understanding of the application protocol so that your solution can understand.

How to splice the streams when a new connection comes in.

Whether or not messages should be stored when the data source is connected by the data recipient is not.

Whether an end to end acknowledgement mechanism is appropriate to prevent message loss.

Whether some kind of application level "ping" mechanism is needed to speed up detection of dead connections.

edited Aug 18 at 22:33

answered Aug 17 at 17:31

Peter Green

2,565420

All good points, but in this case the application protocol is very simple. Partial messages are easily detected and discarded. Losing messages is not a big problem if connection can be re-established quickly enough.
â€“Â dtech
Aug 20 at 13:08

add a commentÂ |Â

Your Answer

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "2"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);

);

draft saved

draft discarded

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f926829%2fhow-to-set-up-a-persistent-tcp-gender-changer-proxy%23new-answer', 'question_page');

);

Post as a guest

Name

2 Answers
2

active

oldest

votes

2 Answers
2

active

oldest

votes

up vote
10
down vote

accepted

How about setting up the socat as a [x]inetd service?

You would set xinetd to listen in PORT-B, and start the socat -u TCP4-LISTEN:PORT-A,reuseaddr STDIO as soon as the B-side connects.

xinetd will pass the incoming traffic from B-side to standard input of socat, and catch the standard output of socat and pass it to the B-side.

If B disconnects, then the socat process can be allowed to end; xinetd will start a new one as soon as B connects again. While B is disconnected, A will be getting "connection refused" errors.

I once had to do something quite similar on an old HP-UX system.

answered Aug 17 at 12:42

telcoM

2,149513

A will attempt to reconnect on an interval on loss of connection, so that is covered. xinetd seems like it could work. Will try and report back, thanks!
â€“Â dtech
Aug 17 at 13:10

It solves the most important problem: that the services can re-establish connection on failure. Thanks!
â€“Â dtech
Aug 20 at 13:06

add a commentÂ |Â

up vote
10
down vote

accepted

How about setting up the socat as a [x]inetd service?

You would set xinetd to listen in PORT-B, and start the socat -u TCP4-LISTEN:PORT-A,reuseaddr STDIO as soon as the B-side connects.

xinetd will pass the incoming traffic from B-side to standard input of socat, and catch the standard output of socat and pass it to the B-side.

If B disconnects, then the socat process can be allowed to end; xinetd will start a new one as soon as B connects again. While B is disconnected, A will be getting "connection refused" errors.

I once had to do something quite similar on an old HP-UX system.

answered Aug 17 at 12:42

telcoM

2,149513

A will attempt to reconnect on an interval on loss of connection, so that is covered. xinetd seems like it could work. Will try and report back, thanks!
â€“Â dtech
Aug 17 at 13:10

It solves the most important problem: that the services can re-establish connection on failure. Thanks!
â€“Â dtech
Aug 20 at 13:06

add a commentÂ |Â

up vote
10
down vote

accepted

How about setting up the socat as a [x]inetd service?

You would set xinetd to listen in PORT-B, and start the socat -u TCP4-LISTEN:PORT-A,reuseaddr STDIO as soon as the B-side connects.

xinetd will pass the incoming traffic from B-side to standard input of socat, and catch the standard output of socat and pass it to the B-side.

If B disconnects, then the socat process can be allowed to end; xinetd will start a new one as soon as B connects again. While B is disconnected, A will be getting "connection refused" errors.

I once had to do something quite similar on an old HP-UX system.

answered Aug 17 at 12:42

telcoM

2,149513

How about setting up the socat as a [x]inetd service?

You would set xinetd to listen in PORT-B, and start the socat -u TCP4-LISTEN:PORT-A,reuseaddr STDIO as soon as the B-side connects.

xinetd will pass the incoming traffic from B-side to standard input of socat, and catch the standard output of socat and pass it to the B-side.

If B disconnects, then the socat process can be allowed to end; xinetd will start a new one as soon as B connects again. While B is disconnected, A will be getting "connection refused" errors.

I once had to do something quite similar on an old HP-UX system.

answered Aug 17 at 12:42

telcoM

2,149513

answered Aug 17 at 12:42

telcoM

2,149513

answered Aug 17 at 12:42

telcoM

2,149513

answered Aug 17 at 12:42

telcoM

2,149513

A will attempt to reconnect on an interval on loss of connection, so that is covered. xinetd seems like it could work. Will try and report back, thanks!
â€“Â dtech
Aug 17 at 13:10

It solves the most important problem: that the services can re-establish connection on failure. Thanks!
â€“Â dtech
Aug 20 at 13:06

add a commentÂ |Â

A will attempt to reconnect on an interval on loss of connection, so that is covered. xinetd seems like it could work. Will try and report back, thanks!
â€“Â dtech
Aug 17 at 13:10

It solves the most important problem: that the services can re-establish connection on failure. Thanks!
â€“Â dtech
Aug 20 at 13:06

A will attempt to reconnect on an interval on loss of connection, so that is covered. xinetd seems like it could work. Will try and report back, thanks!
â€“Â dtech
Aug 17 at 13:10

It solves the most important problem: that the services can re-establish connection on failure. Thanks!
â€“Â dtech
Aug 20 at 13:06

add a commentÂ |Â

up vote
3
down vote

The real world is messy.

If the connection is initiated from sender to recipiant then a new connection may come in while the old connection is apparently still alive.

If the connection is initiated from recipiant to sender then there may be a substantial delay between the sender detecting the connection is broken and the recipiant detecting that fact and triggering a reconnection.

Furthermore TCP connections are a stream of bytes, NOT a stream of messages, so when your connection dies you may receive a partial message.

The net result of this leads me to conclude that a robust solution requires an understanding of the application protocol so that your solution can understand.

How to splice the streams when a new connection comes in.

Whether or not messages should be stored when the data source is connected by the data recipient is not.

Whether an end to end acknowledgement mechanism is appropriate to prevent message loss.

Whether some kind of application level "ping" mechanism is needed to speed up detection of dead connections.

edited Aug 18 at 22:33

answered Aug 17 at 17:31

Peter Green

2,565420

All good points, but in this case the application protocol is very simple. Partial messages are easily detected and discarded. Losing messages is not a big problem if connection can be re-established quickly enough.
â€“Â dtech
Aug 20 at 13:08

add a commentÂ |Â

up vote
3
down vote

The real world is messy.

If the connection is initiated from sender to recipiant then a new connection may come in while the old connection is apparently still alive.

If the connection is initiated from recipiant to sender then there may be a substantial delay between the sender detecting the connection is broken and the recipiant detecting that fact and triggering a reconnection.

Furthermore TCP connections are a stream of bytes, NOT a stream of messages, so when your connection dies you may receive a partial message.

The net result of this leads me to conclude that a robust solution requires an understanding of the application protocol so that your solution can understand.

How to splice the streams when a new connection comes in.

Whether or not messages should be stored when the data source is connected by the data recipient is not.

Whether an end to end acknowledgement mechanism is appropriate to prevent message loss.

Whether some kind of application level "ping" mechanism is needed to speed up detection of dead connections.

edited Aug 18 at 22:33

answered Aug 17 at 17:31

Peter Green

2,565420

All good points, but in this case the application protocol is very simple. Partial messages are easily detected and discarded. Losing messages is not a big problem if connection can be re-established quickly enough.
â€“Â dtech
Aug 20 at 13:08

add a commentÂ |Â

up vote
3
down vote

The real world is messy.

If the connection is initiated from sender to recipiant then a new connection may come in while the old connection is apparently still alive.

If the connection is initiated from recipiant to sender then there may be a substantial delay between the sender detecting the connection is broken and the recipiant detecting that fact and triggering a reconnection.

Furthermore TCP connections are a stream of bytes, NOT a stream of messages, so when your connection dies you may receive a partial message.

The net result of this leads me to conclude that a robust solution requires an understanding of the application protocol so that your solution can understand.

How to splice the streams when a new connection comes in.

Whether or not messages should be stored when the data source is connected by the data recipient is not.

Whether an end to end acknowledgement mechanism is appropriate to prevent message loss.

Whether some kind of application level "ping" mechanism is needed to speed up detection of dead connections.

edited Aug 18 at 22:33

answered Aug 17 at 17:31

Peter Green

2,565420

The real world is messy.

If the connection is initiated from sender to recipiant then a new connection may come in while the old connection is apparently still alive.

If the connection is initiated from recipiant to sender then there may be a substantial delay between the sender detecting the connection is broken and the recipiant detecting that fact and triggering a reconnection.

Furthermore TCP connections are a stream of bytes, NOT a stream of messages, so when your connection dies you may receive a partial message.

The net result of this leads me to conclude that a robust solution requires an understanding of the application protocol so that your solution can understand.

How to splice the streams when a new connection comes in.

Whether or not messages should be stored when the data source is connected by the data recipient is not.

Whether an end to end acknowledgement mechanism is appropriate to prevent message loss.

Whether some kind of application level "ping" mechanism is needed to speed up detection of dead connections.

edited Aug 18 at 22:33

answered Aug 17 at 17:31

Peter Green

2,565420

edited Aug 18 at 22:33

answered Aug 17 at 17:31

Peter Green

2,565420

answered Aug 17 at 17:31

Peter Green

2,565420

answered Aug 17 at 17:31

Peter Green

2,565420

All good points, but in this case the application protocol is very simple. Partial messages are easily detected and discarded. Losing messages is not a big problem if connection can be re-established quickly enough.
â€“Â dtech
Aug 20 at 13:08

add a commentÂ |Â

All good points, but in this case the application protocol is very simple. Partial messages are easily detected and discarded. Losing messages is not a big problem if connection can be re-established quickly enough.
â€“Â dtech
Aug 20 at 13:08

All good points, but in this case the application protocol is very simple. Partial messages are easily detected and discarded. Losing messages is not a big problem if connection can be re-established quickly enough.
â€“Â dtech
Aug 20 at 13:08

add a commentÂ |Â

draft saved

draft discarded

draft saved

draft discarded

Post as a guest

Name

Search This Blog

Iyfjky