[sip-comm-dev] Re: svn commit: r7043 - zrtp/ZRTPTransformEngine.java


#1

Hey Werner,

На 26.04.10 14:08, wernerd@dev.java.net написа:

Author: wernerd
Date: 2010-04-26 12:08:31+0000
New Revision: 7043

Modified:
   trunk/src/net/java/sip/communicator/impl/neomedia/transform/zrtp/ZRTPTransformEngine.java

Log:
TimeoutProvider is not a daemon thread.

I am a bit confused why this is the case here. Do we really want this
thread to prevent SIP Communicator from exiting?

Cheers,
Emil

···

Modified: trunk/src/net/java/sip/communicator/impl/neomedia/transform/zrtp/ZRTPTransformEngine.java
Url: https://sip-communicator.dev.java.net/source/browse/sip-communicator/trunk/src/net/java/sip/communicator/impl/neomedia/transform/zrtp/ZRTPTransformEngine.java?view=diff&rev=7043&p1=trunk/src/net/java/sip/communicator/impl/neomedia/transform/zrtp/ZRTPTransformEngine.java&p2=trunk/src/net/java/sip/communicator/impl/neomedia/transform/zrtp/ZRTPTransformEngine.java&r1=7042&r2=7043

--- trunk/src/net/java/sip/communicator/impl/neomedia/transform/zrtp/ZRTPTransformEngine.java (original)
+++ trunk/src/net/java/sip/communicator/impl/neomedia/transform/zrtp/ZRTPTransformEngine.java 2010-04-26 12:08:31+0000
@@ -162,7 +162,7 @@
     private class TimeoutProvider extends Thread
     {
         /**
- * Contructs Timeout provider.
+ * Constructs Timeout provider.
          * @param name the name of the provider.
          */
         public TimeoutProvider(String name)
@@ -191,7 +191,7 @@
         private final Object sync = new Object();

         /**
- * Request timout after the specified delay.
+ * Request timeout after the specified delay.
          * @param delay the delay.
          */
         public synchronized void requestTimeout(long delay)
@@ -497,7 +497,7 @@
         if (timeoutProvider == null)
         {
             timeoutProvider = new TimeoutProvider("ZRTP");
- timeoutProvider.setDaemon(true);
+ // timeoutProvider.setDaemon(true); // Daemon only if timeoutprovider is a global singleton
             timeoutProvider.start();
         }

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: commits-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

На 26.04.10 14:19, Emil Ivov написа:

Hey Werner,

На 26.04.10 14:08, wernerd@dev.java.net написа:

Author: wernerd
Date: 2010-04-26 12:08:31+0000
New Revision: 7043

Modified:
   trunk/src/net/java/sip/communicator/impl/neomedia/transform/zrtp/ZRTPTransformEngine.java

Log:
TimeoutProvider is not a daemon thread.

I am a bit confused why this is the case here. Do we really want this
thread to prevent SIP Communicator from exiting?

Just to make this clearer. If you really want this thread to be a
non-daemon thread then you'd have to explicitly set it to false. By
default it would inherit the property from its parent which would make
it a daemon I believe (unless the parent is also non-daemon for some
weird reason?).

The thing is that I don't see why we would want this to be a non-daemon
thread in the first place.

Cheers,
Emil

···

Cheers,
Emil

Modified: trunk/src/net/java/sip/communicator/impl/neomedia/transform/zrtp/ZRTPTransformEngine.java
Url: https://sip-communicator.dev.java.net/source/browse/sip-communicator/trunk/src/net/java/sip/communicator/impl/neomedia/transform/zrtp/ZRTPTransformEngine.java?view=diff&rev=7043&p1=trunk/src/net/java/sip/communicator/impl/neomedia/transform/zrtp/ZRTPTransformEngine.java&p2=trunk/src/net/java/sip/communicator/impl/neomedia/transform/zrtp/ZRTPTransformEngine.java&r1=7042&r2=7043

--- trunk/src/net/java/sip/communicator/impl/neomedia/transform/zrtp/ZRTPTransformEngine.java (original)
+++ trunk/src/net/java/sip/communicator/impl/neomedia/transform/zrtp/ZRTPTransformEngine.java 2010-04-26 12:08:31+0000
@@ -162,7 +162,7 @@
     private class TimeoutProvider extends Thread
     {
         /**
- * Contructs Timeout provider.
+ * Constructs Timeout provider.
          * @param name the name of the provider.
          */
         public TimeoutProvider(String name)
@@ -191,7 +191,7 @@
         private final Object sync = new Object();

         /**
- * Request timout after the specified delay.
+ * Request timeout after the specified delay.
          * @param delay the delay.
          */
         public synchronized void requestTimeout(long delay)
@@ -497,7 +497,7 @@
         if (timeoutProvider == null)
         {
             timeoutProvider = new TimeoutProvider("ZRTP");
- timeoutProvider.setDaemon(true);
+ // timeoutProvider.setDaemon(true); // Daemon only if timeoutprovider is a global singleton
             timeoutProvider.start();
         }

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: commits-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hi Emil,

the TimeoutProvider is a normal thread that inherits its properties from
the parent thread. Also the TimeoutProvider thread will be stopped when
the connection is closed (cleanup function).

I had some smaller problems with TimeoutProvider thread object that were
in status WAITING. However, I will do some more smaller changes during
the next days (using a better random number generator) so I can revert
this if necessary. I'll have a look at this "thread WAITING" problem also.

Regards,
Werner

···

Am 26.04.2010 14:34, schrieb Emil Ivov:

На 26.04.10 14:19, Emil Ivov написа:

Hey Werner,

На 26.04.10 14:08, wernerd@dev.java.net написа:

Author: wernerd
Date: 2010-04-26 12:08:31+0000
New Revision: 7043

Modified:
   trunk/src/net/java/sip/communicator/impl/neomedia/transform/zrtp/ZRTPTransformEngine.java

Log:
TimeoutProvider is not a daemon thread.

I am a bit confused why this is the case here. Do we really want this
thread to prevent SIP Communicator from exiting?

Just to make this clearer. If you really want this thread to be a
non-daemon thread then you'd have to explicitly set it to false. By
default it would inherit the property from its parent which would make
it a daemon I believe (unless the parent is also non-daemon for some
weird reason?).

The thing is that I don't see why we would want this to be a non-daemon
thread in the first place.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hi,

I have a question regarding this TimeoutProvider. From time to time an
zrtp session cannot be started and all I see in the console is:
FINE: impl.neomedia.transform.zrtp.SecurityEventManager.zrtpNegotiationFailed().324
AUDIO_SESSION: ZRTP key negotiation failed, sub code: SevereCannotSend

After looking at this I saw that this comes from the TimeoutProvider.
Is this the problem you were talking about.
Here is the stacktrace:

java.lang.Exception
  at net.java.sip.communicator.impl.neomedia.transform.zrtp.SecurityEventManager.zrtpNegotiationFailed(SecurityEventManager.java:325)
  at net.java.sip.communicator.impl.neomedia.transform.zrtp.ZRTPTransformEngine.zrtpNegotiationFailed(ZRTPTransformEngine.java:895)
  at gnu.java.zrtp.ZRtp.zrtpNegotiationFailed(ZRtp.java:2029)
  at gnu.java.zrtp.ZrtpStateClass.sendFailed(ZrtpStateClass.java:1612)
  at gnu.java.zrtp.ZrtpStateClass.evCommitSent(ZrtpStateClass.java:1068)
  at gnu.java.zrtp.ZrtpStateClass.dispatchEvent(ZrtpStateClass.java:286)
  at gnu.java.zrtp.ZrtpStateClass.processEvent(ZrtpStateClass.java:246)
  at gnu.java.zrtp.ZRtp.processTimeout(ZRtp.java:446)
  at net.java.sip.communicator.impl.neomedia.transform.zrtp.ZRTPTransformEngine.handleTimeout(ZRTPTransformEngine.java:868)
  at net.java.sip.communicator.impl.neomedia.transform.zrtp.ZRTPTransformEngine$TimeoutProvider.run(ZRTPTransformEngine.java:272)

Thanks
damencho

···

On Mon, Apr 26, 2010 at 9:18 PM, Werner Dittmann <Werner.Dittmann@t-online.de> wrote:

Hi Emil,

the TimeoutProvider is a normal thread that inherits its properties from
the parent thread. Also the TimeoutProvider thread will be stopped when
the connection is closed (cleanup function).

I had some smaller problems with TimeoutProvider thread object that were
in status WAITING. However, I will do some more smaller changes during
the next days (using a better random number generator) so I can revert
this if necessary. I'll have a look at this "thread WAITING" problem also.

Regards,
Werner

Am 26.04.2010 14:34, schrieb Emil Ivov:

На 26.04.10 14:19, Emil Ivov написа:

Hey Werner,

На 26.04.10 14:08, wernerd@dev.java.net написа:

Author: wernerd
Date: 2010-04-26 12:08:31+0000
New Revision: 7043

Modified:
trunk/src/net/java/sip/communicator/impl/neomedia/transform/zrtp/ZRTPTransformEngine.java

Log:
TimeoutProvider is not a daemon thread.

I am a bit confused why this is the case here. Do we really want this
thread to prevent SIP Communicator from exiting?

Just to make this clearer. If you really want this thread to be a
non-daemon thread then you'd have to explicitly set it to false. By
default it would inherit the property from its parent which would make
it a daemon I believe (unless the parent is also non-daemon for some
weird reason?).

The thing is that I don't see why we would want this to be a non-daemon
thread in the first place.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Damian,

this is not a problem of the timeout provider thead. During the
ZRTP negotiation phase a timeout happen and the ZRTP protocol
state engine tries to resend a packet via the RTP socket but
this send failed for some reason. I've never seen this happen
because once a RTP datagram socket was established there are a
very few reasons why you can't send data.

This information should also trigger a popo-up or some information
on the screen. However, that is not implement in the SecurityManager
(need to put it onto my TODO list)

The only way to fail for "sendDataZRTP (in ZRTPTransformEngine) is
an IOException, but then you should also see an warning entry in
the log file.

Why the SecurityEventManager throws an exception - I don't know because
there is no reason. The SecurityEventManager just logs the event and
returns.

But the original problem seems strang too: why ZRTP can't send a packet
via the RTP datagram socket anymore? It's in the middle of the nedotiation
phase, this it work just a few ms before.

Regards,
Werner

···

Am 28.04.2010 12:41, schrieb Damian Minkov:

Hi,

I have a question regarding this TimeoutProvider. From time to time an
zrtp session cannot be started and all I see in the console is:
FINE: impl.neomedia.transform.zrtp.SecurityEventManager.zrtpNegotiationFailed().324
AUDIO_SESSION: ZRTP key negotiation failed, sub code: SevereCannotSend

After looking at this I saw that this comes from the TimeoutProvider.
Is this the problem you were talking about.
Here is the stacktrace:

java.lang.Exception
  at net.java.sip.communicator.impl.neomedia.transform.zrtp.SecurityEventManager.zrtpNegotiationFailed(SecurityEventManager.java:325)
  at net.java.sip.communicator.impl.neomedia.transform.zrtp.ZRTPTransformEngine.zrtpNegotiationFailed(ZRTPTransformEngine.java:895)
  at gnu.java.zrtp.ZRtp.zrtpNegotiationFailed(ZRtp.java:2029)
  at gnu.java.zrtp.ZrtpStateClass.sendFailed(ZrtpStateClass.java:1612)
  at gnu.java.zrtp.ZrtpStateClass.evCommitSent(ZrtpStateClass.java:1068)
  at gnu.java.zrtp.ZrtpStateClass.dispatchEvent(ZrtpStateClass.java:286)
  at gnu.java.zrtp.ZrtpStateClass.processEvent(ZrtpStateClass.java:246)
  at gnu.java.zrtp.ZRtp.processTimeout(ZRtp.java:446)
  at net.java.sip.communicator.impl.neomedia.transform.zrtp.ZRTPTransformEngine.handleTimeout(ZRTPTransformEngine.java:868)
  at net.java.sip.communicator.impl.neomedia.transform.zrtp.ZRTPTransformEngine$TimeoutProvider.run(ZRTPTransformEngine.java:272)

Thanks
damencho

On Mon, Apr 26, 2010 at 9:18 PM, Werner Dittmann > <Werner.Dittmann@t-online.de> wrote:

Hi Emil,

the TimeoutProvider is a normal thread that inherits its properties from
the parent thread. Also the TimeoutProvider thread will be stopped when
the connection is closed (cleanup function).

I had some smaller problems with TimeoutProvider thread object that were
in status WAITING. However, I will do some more smaller changes during
the next days (using a better random number generator) so I can revert
this if necessary. I'll have a look at this "thread WAITING" problem also.

Regards,
Werner

Am 26.04.2010 14:34, schrieb Emil Ivov:

На 26.04.10 14:19, Emil Ivov написа:

Hey Werner,

На 26.04.10 14:08, wernerd@dev.java.net написа:

Author: wernerd
Date: 2010-04-26 12:08:31+0000
New Revision: 7043

Modified:
   trunk/src/net/java/sip/communicator/impl/neomedia/transform/zrtp/ZRTPTransformEngine.java

Log:
TimeoutProvider is not a daemon thread.

I am a bit confused why this is the case here. Do we really want this
thread to prevent SIP Communicator from exiting?

Just to make this clearer. If you really want this thread to be a
non-daemon thread then you'd have to explicitly set it to false. By
default it would inherit the property from its parent which would make
it a daemon I believe (unless the parent is also non-daemon for some
weird reason?).

The thing is that I don't see why we would want this to be a non-daemon
thread in the first place.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Hi,

Damian,

this is not a problem of the timeout provider thead. During the
ZRTP negotiation phase a timeout happen and the ZRTP protocol
state engine tries to resend a packet via the RTP socket but
this send failed for some reason. I've never seen this happen
because once a RTP datagram socket was established there are a
very few reasons why you can't send data.

This information should also trigger a popo-up or some information
on the screen. However, that is not implement in the SecurityManager
(need to put it onto my TODO list)

The only way to fail for "sendDataZRTP (in ZRTPTransformEngine) is
an IOException, but then you should also see an warning entry in
the log file.

Why the SecurityEventManager throws an exception - I don't know because
there is no reason. The SecurityEventManager just logs the event and
returns.

:slight_smile: That's me. Cause I've saw that problem and have seen the log in the
console I put there that stack trace print in order to catch from
where it comes originally.

But the original problem seems strang too: why ZRTP can't send a packet
via the RTP datagram socket anymore? It's in the middle of the nedotiation
phase, this it work just a few ms before.

It happens only from time to time, but why I can't figure it out either.

Cheers
damencho

···

On Wed, Apr 28, 2010 at 7:09 PM, Werner Dittmann <Werner.Dittmann@t-online.de> wrote:

Regards,
Werner

Am 28.04.2010 12:41, schrieb Damian Minkov:

Hi,

I have a question regarding this TimeoutProvider. From time to time an
zrtp session cannot be started and all I see in the console is:
FINE: impl.neomedia.transform.zrtp.SecurityEventManager.zrtpNegotiationFailed().324
AUDIO_SESSION: ZRTP key negotiation failed, sub code: SevereCannotSend

After looking at this I saw that this comes from the TimeoutProvider.
Is this the problem you were talking about.
Here is the stacktrace:

java.lang.Exception
at net.java.sip.communicator.impl.neomedia.transform.zrtp.SecurityEventManager.zrtpNegotiationFailed(SecurityEventManager.java:325)
at net.java.sip.communicator.impl.neomedia.transform.zrtp.ZRTPTransformEngine.zrtpNegotiationFailed(ZRTPTransformEngine.java:895)
at gnu.java.zrtp.ZRtp.zrtpNegotiationFailed(ZRtp.java:2029)
at gnu.java.zrtp.ZrtpStateClass.sendFailed(ZrtpStateClass.java:1612)
at gnu.java.zrtp.ZrtpStateClass.evCommitSent(ZrtpStateClass.java:1068)
at gnu.java.zrtp.ZrtpStateClass.dispatchEvent(ZrtpStateClass.java:286)
at gnu.java.zrtp.ZrtpStateClass.processEvent(ZrtpStateClass.java:246)
at gnu.java.zrtp.ZRtp.processTimeout(ZRtp.java:446)
at net.java.sip.communicator.impl.neomedia.transform.zrtp.ZRTPTransformEngine.handleTimeout(ZRTPTransformEngine.java:868)
at net.java.sip.communicator.impl.neomedia.transform.zrtp.ZRTPTransformEngine$TimeoutProvider.run(ZRTPTransformEngine.java:272)

Thanks
damencho

On Mon, Apr 26, 2010 at 9:18 PM, Werner Dittmann >> <Werner.Dittmann@t-online.de> wrote:

Hi Emil,

the TimeoutProvider is a normal thread that inherits its properties from
the parent thread. Also the TimeoutProvider thread will be stopped when
the connection is closed (cleanup function).

I had some smaller problems with TimeoutProvider thread object that were
in status WAITING. However, I will do some more smaller changes during
the next days (using a better random number generator) so I can revert
this if necessary. I'll have a look at this "thread WAITING" problem also.

Regards,
Werner

Am 26.04.2010 14:34, schrieb Emil Ivov:

На 26.04.10 14:19, Emil Ivov написа:

Hey Werner,

На 26.04.10 14:08, wernerd@dev.java.net написа:

Author: wernerd
Date: 2010-04-26 12:08:31+0000
New Revision: 7043

Modified:
trunk/src/net/java/sip/communicator/impl/neomedia/transform/zrtp/ZRTPTransformEngine.java

Log:
TimeoutProvider is not a daemon thread.

I am a bit confused why this is the case here. Do we really want this
thread to prevent SIP Communicator from exiting?

Just to make this clearer. If you really want this thread to be a
non-daemon thread then you'd have to explicitly set it to false. By
default it would inherit the property from its parent which would make
it a daemon I believe (unless the parent is also non-daemon for some
weird reason?).

The thing is that I don't see why we would want this to be a non-daemon
thread in the first place.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net