kkl wrote:If possible, I would suggest that all additional clients connect to computer 1. If computer 2 is off, computer 3 will have nothing to connect to.
I know. I was just busting your ass. but you could daisy chain them like that if you wanted.
and I also think because the commands are really small and the communication is very limited. that i will be able to use non blocking sockets instead of select to handle the multiple connections. But i would have to use object locking and set up 2 threads to do this. one to just handle the communications and if an event comes in have it load the queue with the event. so the other thread it's sole purpose would be to empty the queue and process the data and trigger any events. If i run into an issue I could set up a 3rd to take care of the forwarding...
I think this is going to be the best for fast response.
1 thread set up to read data coming from the AVR and process any messages and trigger an event if needs be. but when it gets the data. that thread will place it into a queue. this can be a blocking socket connection. meaning it will just sit there and do nothing unless it gets something from the AVR.
a second thread will read that queue and send the data out to all of the other connected devices. and it will also take care of getting any data from any of the connected devices and sending it out to the AVR
I think this will be the best solution. but if for some reason there is an issue with speed i can figure something out.
I am going to hammer out the connection bits tonight..
@kkl. I have that list of commands if you want to do the ever so boring job of keying in nice friendly descriptions and event names. I just have to finish up keying in some comments but the way you see it laid out has to stay that way. for the time being. I can convert it from there. if this is something you wish to on take let me know.
Also I am going to add being able to use a serial connection as well. because the API is the same for TCP and Serial.