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

[Artem Smotrakov]

Hi Mike,

On 06/28/2016 10:36 AM, Michael StJohns wrote:
> 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.
Agree. Solaris is just an example that the loopback address may not use 
real network stack.
>>
>> 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.
Thank you for this link! That's really useful for me, recently I was 
looking for similar tools like "tc".

Artem
>
> 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
>>
>