Here is an updated webrev which includes a fix for 8161086 (thanks
Xuelei for help):
- No updates to the problem list
- CustomDatagramSocketImplFactory drops 5% of packets by default
- Updated DTLSInputRecord and DTLSOutputRecord to print sequence numbers
if -Djavax.net.debug=ssl option is specified
- Updated InvalidRecords.java tests not to drop packets by default
because handshaking unexpectedly succeeds if an invalid packet was dropped
http://cr.openjdk.java.net/~asmotrak/8159416/webrev.03/
Please take a look.
Artem
On 07/28/2016 04:36 PM, Artem Smotrakov wrote:
Hi Xuelei,
I updated CustomDatagramSocketImpl class to be able to drop some
packets randomly or by specified numbers.
While updating the test, I found
https://bugs.openjdk.java.net/browse/JDK-8161086 which I think is the
root cause of these intermittent failures.
I added a couple of PacketLoss* tests to reproduce and verify 8161086.
These tests drop different packets while handshaking. They use
different cipher suites and modes, so that they take a while. I didn't
notice they fail with timeout, but I suspect that may happen on slower
machines. That's why I increased timeout value for them. I added the
tests to the problem list since 8161086 is not fixed yet.
There are a couple of other updates to DTLSOverDatagram.java:
- Server tries to receive first application data when it finishes
handshaking. Server re-sends final handshaking messages if timeout
reached while waiting for application data from client.
- Updated client and server to use simple threads instead of thread
pools. This way, it's possible to specify meaningful names for threads
which makes logs more readable if "-Djavax.net.debug=ssl" specified
- Added more logging
- Made some fields final
At the moment, CustomDatagramSocketImplFactory doesn't drop packets by
default because it may cause intermittent failures of tests which are
based on DTLSOverDatagram class:
...
static class CustomDatagramSocketImplFactory
implements DatagramSocketImplFactory {
...
// if true, it's going to drop some packets
private static boolean dropPackets = false;
...
When 8161086 is fixed, it may be set to true by default. Currently the
packet loss rate is 5% which I think is much more than if we use UDP
sockets on localhost, so that we test DTLS impl in worse conditions.
Could you please take a look at updated webrev?
http://cr.openjdk.java.net/~asmotrak/8159416/webrev.02/
Artem
On 06/27/2016 06:25 PM, Xuelei Fan wrote:
On 6/28/2016 9:12 AM, Artem Smotrakov wrote:
Hello,
Please review this patch for javax/net/ssl/DTLS tests.
A couple of DTLS tests fail intermittently on Mac with timeout or "Too
many handshake loops ..." error. The tests use UDP to transfer DTLS
records. It happens sometimes that server cannot receive UDP packets
with DatagramSocket.receive() method even if client tries to re-send
them multiple times. Please see logs in the bug.
At the moment, it is not clear why UDP packets can't be delivered to
server. If someone has seen something similar before, or has some ideas
what might be the root cause, please let me know.
UDP is not reliable. It could happen that the packets get lost.
I think that the tests and DTLS implementation are fine here. Since the
tests are for DTLS, we can workaround this issue by avoiding real UDP
connections. To avoid changing test logic much, we can use a custom
DatagramSocketImpl and DatagramSocketImplFactory implementations to
replace system UDP implementation.
The patch below updates the tests with the following:
- added custom DatagramSocketImpl and DatagramSocketImplFactory
implementations to avoid real UDP connections
Tests for real connections in practice are needed. If we update this
test this way, we need to add other tests to test real application
usage. I don't think this is the right direction to avoid real UDP
connections.
- added more test output, so that we can have more info it the tests
fail again
I agree with this point.
Xuelei
I have run javax/net/ssl/DTLS/CipherSuite.java test in a loop on Mac,
and I didn't see it failed. I also have run javax/net/ssl/DTLS tests on
all supported generic platforms, and they worked fine.
Bug: https://bugs.openjdk.java.net/browse/JDK-8159416
http://cr.openjdk.java.net/~asmotrak/8159416/webrev.00/
Artem
