[ 
https://issues.apache.org/jira/browse/NET-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chuck Wolber updated NET-410:
-----------------------------

    Description: 
org.apache.commons.net.tftp.TFTPClient

When a packet fails to be received, the looping logic in TFTPClient contains an 
unlabeled "continue" in the TFTPTimeout blocks. This causes TFTPClient to go 
back to the listening state in the innermost loop, rather than the sendPacket 
label in the outermost loop (which will cause a resend of the missing packet). 

Note: This issue is not as simple as adding the _sendPacket label to the 
continue statement in the TFTPTimeout blocks. Doing so will expose the code to 
the Sorcerer's Apprentice Syndrome as defined in RFC 1123 section 4.2.3.1

  was:
org.apache.commons.net.tftp.TFTPClient

When a packet fails to be received,the looping logic in TFTPClient contains an 
unlabeled "continue" in the TFTPTimeout blocks. This causes TFTPClient to go 
back to the listening state in the innermost loop, rather than the sendPacket 
label in the outermost loop (which will cause a resend of the missing packet). 

Note: This issue is not as simple as adding the _sendPacket label to the 
continue statement in the TFTPTimeout blocks. Doing so will expose the code to 
the Sorcerer's Apprentice Syndrome as defined in RFC 1123 section 4.2.3.1


> Apache Commons TFTP does not handle RFC 783 retransmits.
> --------------------------------------------------------
>
>                 Key: NET-410
>                 URL: https://issues.apache.org/jira/browse/NET-410
>             Project: Commons Net
>          Issue Type: Bug
>          Components: TFTP
>    Affects Versions: 2.2, 3.0
>         Environment: Sun/Oracle JRE 6 update 20
>            Reporter: Chuck Wolber
>
> org.apache.commons.net.tftp.TFTPClient
> When a packet fails to be received, the looping logic in TFTPClient contains 
> an unlabeled "continue" in the TFTPTimeout blocks. This causes TFTPClient to 
> go back to the listening state in the innermost loop, rather than the 
> sendPacket label in the outermost loop (which will cause a resend of the 
> missing packet). 
> Note: This issue is not as simple as adding the _sendPacket label to the 
> continue statement in the TFTPTimeout blocks. Doing so will expose the code 
> to the Sorcerer's Apprentice Syndrome as defined in RFC 1123 section 4.2.3.1

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to