On 6/28/2016 1:02 PM, Artem Smotrakov wrote:
Hi Xuelei,
Even if the tests keep using UDP to transfer data, they may not be
realistic since they run on local host. UDP implementation is based on
functions provided by OS. If I remember correctly, Solaris may do some
optimizations for localhost connections, so that no real networking
stack is used at all.
Generically, the loopback address (127.0.0.1) is treated only marginally
differently from using the normal interface IP address. I'm not sure
what Solaris does, but for the most part you should be fine if you use
one of the real interface addresses.
If we want to test DTLS with real connections, I believe we should do
the following:
1. Use two different machines
2. Make tests expect some issues with network and other environment
Instead take a look at
https://sandilands.info/sgordon/dropping-packets-in-ubuntu-linux-using-tc-and-iptables
- depending on the availability of these commands and functions, you
should be able to do the testing on a single machine over the loopback
address and get pseudo-real network behavior.
Mike
#1 requires starting server and client on different hosts which
doesn't seem to be possible with jtreg. Another option is to set up a
remote server.
#2 may require ignoring errors, and re-trying connections. I am not
sure that we want to update existing tests with this.
I think it is better to focus on DTLS testing, and make tests more
stable. That's why I am proposing to use custom UDP sockets. If we
want to test real connections, then it should be different tests which
take into account #1 and #2 above.
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
