[9] RFR: 8159416: javax/net/ssl/DTLS/CipherSuite.java failed on timeout

[Michael StJohns]

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
>