The bug reported here interferes with the message flow between clients (such as Translator) and IrServer. The symptoms are intermittent and infrequent, but include missing or corrupted IR blasts. The problems are more likely to occur under high system load (e.g. shortly after resume from standby).
IrssComms assumes that one Socket.Send always corresponds with one Socket.Receive, i.e. that message boundaries are respected on the communication link. This assumption happens to be almost always correct for the kind of traffic generated in IRSS. However, the system will sometimes deliver a message in more than one part. When this happens, IrssComms causes the client (e.g. Translator) to disconnect. Translator will promptly reconnect, but in the meantime information will have been lost.
Fortunately, coming up with a solution was easier than tracking the problem down (see the attached 2 source code modules).
Removing this bug has improved performance for me, and may also help other users who have reported occasional IR blasting errors.
Could one of the devs please respond.
Thanks
===
Patch updated 2010-02-19
IrssComms assumes that one Socket.Send always corresponds with one Socket.Receive, i.e. that message boundaries are respected on the communication link. This assumption happens to be almost always correct for the kind of traffic generated in IRSS. However, the system will sometimes deliver a message in more than one part. When this happens, IrssComms causes the client (e.g. Translator) to disconnect. Translator will promptly reconnect, but in the meantime information will have been lost.
Fortunately, coming up with a solution was easier than tracking the problem down (see the attached 2 source code modules).
Removing this bug has improved performance for me, and may also help other users who have reported occasional IR blasting errors.
Could one of the devs please respond.
Thanks
===
Patch updated 2010-02-19
Germany
for the patch, it is currently being reviewed.