Java BUMP implementation.

wump_client_outline.html

Outline of the wump client program main loop.

There are three states:

1. UNLATCHED, until we get a good DATA[1] from the new port
2. LATCHED, once we've latched on to the new port
3. DALLY, after we've received the final data packet

Here's a first pass at a pseudocode outline of the main body of the program, as presented on June 6; while it is pseudocode, note that while(true) and continue are legitimate java. Note how the use of continue makes elses unnecessary. There are three main problems here: dally() is unspecified, the transition from UNLATCHED to LATCHED is unclear (and the program does not implement it correctly, clear or not), and the timeout-event handling is, well, incomplete. On June 6 we did discuss the transition to LATCHED. while (true) {         replyDG = s.receive()    // possibly a timeout         if TIMEOUT:                 retransmit previous packet (ACK or REQ)                 continue         wrong IP addr:                 continue         wrong port:            // really separate from wrong IP-addr                 send error packet                 continue         wrong length:    // can't even check for DATA opcode if there aren't enough bytes!                 continue         not DATA                 continue         create DATA packet out of replyDG         wrong blocknum:                 continue         // now we have a good packet!                 write data                 expected_block ++;                 send ACK to destport                 if (size < 512) {                         dally();            // to be discussed                         break;            // done                 } } The first fix is to clarify when we become LATCHED. This occurs when we recognize a valid DATA[1]; at that time we set expected_block >1 so we can use this fact (expected_block > 1) as our "flag". However, we should check for LATCHED early in the game, and we don't find out about valid DATA[1] until late in the loop above. Additions are in green; in most cases we will become LATCHED during the first run through the main while loop. while (true) {         replyDG = s.receive()    // possibly a timeout         if TIMEOUT:                 retransmit previous packet (ACK or REQ)                 continue         wrong IP addr:                 continue         wrong port:            // really separate from wrong IP-addr                 only check port if expected_block == 1                 send error packet                 continue         wrong length:    // can't even check for DATA opcode if there aren't enough bytes!                 continue         not DATA                 continue         create DATA packet out of replyDG         wrong blocknum:                 continue         // now we have a good packet!                 write data                 if expected_block == 1, set destport = replyDG.getport()                 expected_block ++;                 send ACK to destport                 if (size < 512) {                         dally();            // to be discussed                         break;            // done                 } } Now on to the timeout issue. There are two different uses of the term here. Suppose the timeout period is, say, 3000 ms.

• A SocketTimeoutException, meaning that the socket received nothing at all for 3000 ms. Let's call this a "hard timeout".
• It's time to resend. We are expecting Data[N] and haven't received it for at least 3000 ms (though we may have received other things). Let's call this a "soft timeout".

It should be clear that a hard timeout does imply a soft timeout: if you've received nothing, then you certainly haven't received the packet you were waiting for. However, the converse is not true! It is possible for you to receive a steady stream of "noise" packets, that serve to prevent a hard timeout from ever occuring, but because none of them is the correct packet you still have to have a soft timeout. The only way to resolve this is to check for the elapsed time. The current time is always available in System.currentTimeMillis(); you will save that value each time you send a packet:         send_time = System.currentTimeMillis(); Now, the first solution to the soft-timeout problem is to check someplace before any "continue" statements that the elapsed time has not been exceeded. That works, but it turns out that a better solution is to notice that if you check elapsed time for soft timeouts, you no longer really need to do anything for hard timeouts (except restart the loop). The hard-timeout interval becomes the clock granularity, in effect: if the soft-timeout interval is 3000 ms and the hard-timeout interval is 1000 ms, then in the worst case you wait until 3000+1000 = 4000 ms before actually noticing and responding to the soft timeout. Once you have an elapsed-time check, it makes sense to shorten the hard-timeout interval to something very small; 1000 ms or even 250 ms. On every "hard" timeout you check the elapsed time for a "soft" timeout. At this point, a (short) hard timeout no longer implies a (long) soft timeout. Note that, although the elapsed-time check is at the beginning of the loop here, it's never executed immediately after receiving a valid packet because after receiving a valid packet we always update send_time, and the elapsed-time check will then fail until we've had at least once attempt at s.receive(). In other words, you don't need a flag or any special logic to prevent checking the elapsed time immediately after sending: it's harmless then. send REQ send_time = System.currentTimeMilllis(); while (true) {         check elapsed time: if exceeded (ie if a soft timeout),                 resend whatever was sent most recently                 send_time = System.currentTimeMilllis();         replyDG = s.receive()    // possibly a timeout         if HARD_TIMEOUT:                 do nothing!                 continue         wrong IP addr:                 continue         wrong port:            // really separate from wrong IP-addr                 send error packet                 continue         wrong length:    // can't even check for DATA opcode if there aren't enough bytes!                 continue         not DATA                 continue         create DATA packet out of replyDG         wrong blocknum:                 continue         // now we have a good packet!                 write data                 expected_block ++;                 send ACK to destport                 send_time = System.currentTimeMilllis();                                if (size < 512) {                         dally();            // to be discussed                         break;            // done                 } }