<?xml version="1.0" encoding="utf-8"?>
<feed xml:lang="en" xmlns="http://www.w3.org/2005/Atom"><title>Recent changes to 37: TuningProfile</title><link href="https://sourceforge.net/p/beepcore-java/bugs/37/" rel="alternate"/><link href="https://sourceforge.net/p/beepcore-java/bugs/37/feed.atom" rel="self"/><id>https://sourceforge.net/p/beepcore-java/bugs/37/</id><updated>2005-02-04T18:32:19Z</updated><subtitle>Recent changes to 37: TuningProfile</subtitle><entry><title>TuningProfile</title><link href="https://sourceforge.net/p/beepcore-java/bugs/37/" rel="alternate"/><published>2005-02-04T18:32:19Z</published><updated>2005-02-04T18:32:19Z</updated><author><name>Dong Xin</name><uri>https://sourceforge.net/u/dxin/</uri></author><id>https://sourceforge.netc5247fa566e6246c71c010bf4651d5725af27999</id><summary type="html">&lt;div class="markdown_content"&gt;&lt;p&gt;We were trying to implement saslsrp in beepcore. The&lt;br /&gt;
problem&lt;br /&gt;
we found in the current implementation are:&lt;/p&gt;
&lt;p&gt;1. The SEQ message are always sent out before the message &lt;br /&gt;
is processed in non-tuning mode, since we want to&lt;br /&gt;
switch the&lt;br /&gt;
ordinary socket to an SRPsocket, the SEQ message introduces&lt;br /&gt;
difficulties to synchronize a point where both peers&lt;br /&gt;
can safely &lt;br /&gt;
switch the underlying socket.&lt;/p&gt;
&lt;p&gt;2. If we use the tuning mode, both server and client&lt;br /&gt;
side will&lt;br /&gt;
communicate via raw socket layer. Since we have to follow &lt;br /&gt;
the SASLProfile to implement SASLSRP, this TLS like&lt;br /&gt;
approach&lt;br /&gt;
is not desirable.&lt;/p&gt;
&lt;p&gt;We made two patch files for ChannelImpl and Channel to fix &lt;br /&gt;
the above problems. More specifically, we add more&lt;br /&gt;
state variables&lt;br /&gt;
which help us still use the beepcore framework while in&lt;br /&gt;
tuning.&lt;/p&gt;&lt;/div&gt;</summary></entry></feed>