ART@ACC.ARPA (Art Berggreen) (10/11/85)
> The problem lies in the LH/DH-11 IMP interface. > Sometimes, most likely always, it will not set the <END OF MESSAGE> > flag in the control & status register if the input buffer is filled > at the same time that <LAST BIT SIGNAL> from the > IMP comes up. > > This causes the LH/DH driver to append the next > incoming message from the IMP to the the previous message. > This process (appending of messages) will continue until > a message SHORTER then the input buffer size is sent -- > a RFNM response does nicely. > > This results in the LOSS of the succeeding messages (e.g. RFNMs) > since the 1822 protocol handling code expects to get only > <ONE> message from the LH/DH at a time. Being the original designer of the LH/DH (it's amazing how fast 10 yrs passes!) this piqued my interest, so I decided to have a chat with the folks who currently have responsibility for these beasts. Unless the LH/DH is of VERY early vintage, this problem should not occur. I hope to find some time (I am probably dreaming about having time) and do some experimentation. The described problem would appear to happen ONLY if a message from the IMP is one word longer than the buffer being read into. When the buffer fills, leaving the data that contains the Last Bit in the LH/DH data buffer, the Receive DMA terminates and the EOM flag is NOT ON (because the user has not yet DMA'd the End-of-Message into memory). What should happen when the Receive DMA is restarted, is that the remaining word is read into memory and the DMA should terminate with the EOM flag ON. If when the DMA is restarted, the internal EOM status is lost, the following message would be concatenated with the end of previous message. A better solution than reducing IMPMTU would be to use I/O buffers that are slightly larger than IMPMTU (and of course setting the Receive Byte Counter to be larger that any expected message). "Art Berggreen"<Art@ACC.ARPA> ------