Re: Decoupling BEEP Sessions and TCP Connections

> On Mon, 2003-02-17 at 11:50, Chip Bradford wrote:
> > Hi,
> >
> > I am a member of a team working at Harvey Mudd College to implement a
Tunnel
> > profile for RoadRunner. For our implementation, we are thinking it would
be
> > useful to be able to close a BEEP session without closing the underlying
TCP
> > socket and to be able to create a new BEEP session which uses a
previously
> > created socket. We would like to know if there is any support currently
for
> > these actions and, if not, what the best way to implement them would be.
> >
> Hi,
>
> A tuning reset is probably what you are looking for. You can look at the
> "rot13" profile in the RoadRunner source tree or the RR/TLS profile for
> an example on how to do a tuning reset.
>
> / Jonas

This is actually not quite what we need. The Tunnel specification requires a
proxy to have two different BEEP sessions running (for example, one
connection to the client and another one to the final server). Once Tunnel
has been negotiated over these sessions, we need to be able to start passing
bytes transparently (ie, stop trying to interpret traffic as a BEEP stream)
so we would like to be able to close down the BEEP sessions without closing
the underlying sockets. We can then start passing data from one socket to
the other without worry about BEEP getting in the way.

As per a previous suggestion quite a while ago, we had been trying to access
the underlying g_io_channels to pass data. RoadRunner, however, seems to be
reading the data before we are able to. Even if we could get this method
working, closing down the BEEP session would still be prefered since it
ensures that no interpretation of the data will occur and it eliminates any
overhead which might be required to run the RoadRunner BEEP session (this is
important for a proxy which is most likey a firewall/router type machine and
needs to be able to easily handle many connections.)

We haven't been able to find any functionality in the RoadRunner libraries
which fulfills our requirements, but if there is some undocumented feature
that could help us it would be nice to know about it. Since these features
seem potentially usefull beyond our specific needs (the other BEEP
implementations we are using support these things) it might be worth-while
to add them to RoadRunner. If this cannot be done in the near future,
however, we will need to figure out on our own how to startup and shutdown a
BEEP session without affecting the underlying socket. In this case, any
advice you can offer or explaination of the current code you can give would
be greatly appreciated.

- Chip Bradford