Primitive to wait for a packet and terminate connection on timeout

Smack Smack Dev
1

SMACK is an utterly synchronous library, and there are several situations in the stream handshake where we send a packet, wait for a reply and then analyze a boolean variable manipulated by PacketReader.

In the XEP-0198 code, there was a new primitive added for that: sendStanzaAndWaitForNotifyOnLock.

However, this primitive does not allow to distingusih if the timeout was reached without a reply, or if the reply was negative. For stream resumption, encryption and compression, we may not just go on after the timeout, because eventually the server will send the reply and garble our stream. Instead, we need to bail out, terminate the connection and let the handshake start anew.

Therefore, I propose to change sendStanzaAndWaitForNotifyOnLock to throw an exception on timeout, forcing the calling code to re-start the connection (possibly using the next available round-robin server).

2

In https://github.com/Flowdalic/Smack/commit/5a92792489249f5b4788f513fb0b4cf0010e16 8c#commitcomment-7057418 you suggest to have a tri-state variable for “success” / “failure” / “timeout”. I think it would be better to have a (atomic)boolean, and throw instead, as that makes the checking logic in the code more consistent.

3

I think it would be better to have a (atomic)boolean
How do you know that there was nor a positive or negative reponse with just a boolean? The problem is what Object.wait() hasn’t an mechanism to tell us that it timed out, that’s why I suggested the tri-state variable.

4

You can use:

http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/Condition.ht ml#await%28long,%20java.util.concurrent.TimeUnit%29

instead of Object.wait().

5

Good point! In fact it seems that we should look into using ReentrantLock and Condition variables soon.