The system I'm building seperates (through an API) the queueing code and the interface code. This is with a view to implementing 'modules' for different types of device/interface without affecting any of the queueing and application side code. The initial device it'll writing the code for will be syncronous, and the ACK'ing issues will not be a problem. I'll implement a state machine to handle the protocol. All I really need to know at this stage are the issues I've already outlined concerning the sharing of file descriptors and fileevent callbacks. In the future, with more complex interface, the ack'ing issues you've raised will need to be addressed, but at present the details of those interface are not available to me. Cheers, Pete. On Wednesday 18 April 2001 13:18, you wrote: > > On Wednesday 18 April 2001 12:30, you wrote: > > > > A message that gets received or transmitted will involve a form of > > > > acknowledgement to be sent/received, and therefore a writer thread > > > > would also need to read and v.v. > > > > > > And do you have to retransmit a packet if you don't get the ACK for it > > > within a set time? > > > > Yes, this may well be a possiblity. Any thoughts on the other issues I > > raised? > > Well, there's the question of whether you need to detect duplicate > messages from the device, if your ACK isn't received by the device, and > what happens if the device receives a message from you twice because the > ACK from the device didn't make it to you. > > Do packets from the device include an ID that you put in your ACKs? Do > packets to the device include an ID that the device puts in its ACKS to > you? Or are communications synchronous, where the device sends you a > single packet and must receive the ACK before sending the next packet? > What if you send a packet at the same time the device does? You are > each expecting an ACK but instead receive a data packet. Can you > distinguish that case? Does the device handle it correctly?
