Currently the AmbientTalk interpreter makes use of TCP/IP sockets for remote
messaging. It also makes use of 'Outputstream.flush()' to flush bytes of the
network socket. However, it takes flush() returning normally to mean that the
bytes were successfully received at the remote end.
The JDK1.5 documentation makes it clear that flush() does not provide such a
guarantee:
"If the intended destination of this stream is an abstraction provided by the
underlying operating system, for example a file, then flushing the stream
guarantees only that bytes previously written to the stream are passed to the
operating system for writing; it does not guarantee that they are actually
written to a physical device such as a disk drive."
In principle, any CMDTransmitATMessage command should be acknowledged by a new
type of command. Only upon reception of an explicit ack should the sending
actor be allowed to drop and forget the sent AmbientTalk message.
Original issue reported on code.google.com by tvcut...@gmail.com on 28 Jul 2010 at 12:33
Original issue reported on code.google.com by
tvcut...@gmail.comon 28 Jul 2010 at 12:33