RFR: 8310807: java/nio/channels/DatagramChannel/Connect.java timed out [v2]

[Mark Sheppard]

On Thu, 16 Nov 2023 13:42:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor cleanup 3
>
> test/jdk/java/nio/channels/DatagramChannel/Connect.java line 160:
> 
>> 158:                     if (!RESPONSE.equals(cb.toString())) {
>> 159:                         log.println("Initiator received unexpected message: continue waiting");
>> 160:                         continue;
> 
> `DatagramChannel.read(ByteBuffer)`, through the contract of `ReadableByteChannel.read(ByteBuffer)`, says that the number of bytes added into the passed `ByteBuffer` may not always be the remaining space in the buffer. i.e. `dc.read(bb)` may just read in few bytes at a time.
> 
> Do you think that's a practical possibility in the context of this test and would that then mean, in this current proposed form, the `RESPONSE.equals(cb.toString())` will never evaluate to `true` and we would end up looping forever?
> 
> Perhaps we should use the return value of `dc.read(bb)` to determine when to do this response equality check and until then keep accumulating the received bytes?

UDP send and receive is atomic, there are no partial send or receive of a datagram (unlike a stream). Thus the initiator send its message as a complete datagram, then when the responder invokes receive and if the send has been successful, the receive will be the complete datagram sent by the initiator -- no partial datagram. That is unless the datagram is a stray datagram from another source, in which the responder continues to wait for the expected datagram. The reverse is true for the responder, it will receive a complete (atomic) message and echo that back to the initiator

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16661#discussion_r1395931273