5 Sep
2013
5 Sep
'13
3:34 a.m.
I am looking for a solution where I need to connect multiple times over
time to a 3rd party POP3 SSL server using my webmail interface, but that
server only allows me to connect 5 times in 15 minutes.
Meaning: I am looking for a solution where the outbound (real server)
connection stays established even though the inbound connection (client)
temporarily goes away. imapproxy provides such functionality but cannot
be used for other reasons.
Perdition looks like a good solution, but whenever the client terminates
the connection, the associated process terminates as well. On the other
hand I see config parameters such as "timeout" that lead me to the
assumption it could be possible to set up what I need.
Any advise appreciated.
Thanks,
Rick
6 Sep
6 Sep
7:18 a.m.
New subject: keeping the outbound connection connected when client disconnects
On Wed, Sep 04, 2013 at 08:34:02PM -0700, Rick Mombassa wrote:
I am looking for a solution where I need to connect
multiple times over
time to a 3rd party POP3 SSL server using my webmail interface, but that
server only allows me to connect 5 times in 15 minutes.
Meaning: I am looking for a solution where the outbound (real server)
connection stays established even though the inbound connection (client)
temporarily goes away. imapproxy provides such functionality but cannot
be used for other reasons.
Perdition looks like a good solution, but whenever the client terminates
the connection, the associated process terminates as well. On the other
hand I see config parameters such as "timeout" that lead me to the
assumption it could be possible to set up what I need.
Hi Rick,
the short answer is that it would be somewhat difficult for perdition
to provide what you are after.
The longer answer is that perdition forks a process after receiving
a connection from a client. In order to support the feature either
* This would need to be changed to use a core process that handled
many connections. This would have other benefits, for example I expect
it would allow perdition to handle many more concurrent connections
that is currently possible. But it would be a major re-work of the code.
* Allow perdition to hand off connections to existing processes.
This is probably easier to implement but I expect it would
be a non-trivial change.
3897
days inactive
3898
days old
1 comments
2 participants
participants (2)
-
Rick Mombassa -
Simon Horman