Brian> Is it just me or is the SANE network protocol full of race
Brian> conditions on replies? There is now way to identify a
Brian> reply. It expects the bytes being read to be associated with
Brian> the last sent packet.
Brian> From what I can tell if you send a packet and the response
Brian> times out you are screwed. It is possible the remote saned
Brian> will still send the bytes, even if you call
Brian> SANE_NET_CANCEL. There is no way (that I can tell) that the
Brian> communication link can recover.
Brian> Even the sends could incorrectly fail under heavy system
Brian> loads, in fact I believe the watch could cause a process
Brian> deadlock. If the alarm triggers before the actual read/write
Brian> will the read timeout?
Brian> Has anyone thought about a simple frame around these things?
You do realize that the SANE network protocol is designed to run on
top of a reliable, ordered bytestream, such as TCP, right?
BTW: as suggested earlier, I think you'd benefit from looking at the
existing source code.
--david
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com