Deadlock when creating Connections
ConnectionEncoder that wraps a
LabCommEncoderChannel explicitly does not send the version string. The constructor of a
LabCommDecoder will always call
decodeString() to get a version from its input stream, which will block if the stream is empty. These two circumstances will always result in a deadlock if a version string cannot be provided in another way. Even if the version string was encoded in the
ConnectionEncoder it would have to be sent to prevent the deadlock from occurring.
Current solution: A solution is provided in the
UDPConnectionMultiplexer, which injects a version string in the
BlockingAppendableInputStream that is assigned to a new
Connection, thus feeding the connection's
Decoder with a correctly formatted version string.
Issue: There are two problems with the above solution.
Version strings are not verified between the sender and the receiver. It is thus possible to connect different versions of Firefly that uses different Labcomm versions.
It does not work for the
TCPConnectionMultiplexer, because the above solution relies on injecting the version string into the input stream used by the connections decoder, which is not possible when using the sockets input stream.
Always encode the version string in the
end(null)on the encoder so the string will be sent. Thus we will both have version checking and have removed the need for version string injection in the
Encode the string as in solution 1 but instead of end(null) add a Labcomm message to the Firfely protocol that is sent upon creating the
Redesign Labcomm so that it is optional to check version upon creating a
LabCommDecoderChannel. However, this will remove the benefit of the version checking in the Labcomm protocol.