jonnosan wrote:
On Jan 3, 8:08 am, "Michael J. Mahon" <mjma...@aol.com> wrote:Another approach would be to have a machine run a "Message Server queue shadow", which would listen promiscuously for traffic between the Message Server and its users, and keep a "shadow" copy of queue status. This machine could then communicate the status to a web- connected machine over a serial link (which would have to not interfere with the timing and constant surveillance of NadaNet (a bit tricky, in itself).An alternative option might be to have a card in one of the machines with an embedded web server (e.g. http://www.futurlec.com/Web_Control_Board.shtml) - this could be wired in to sample the game port pins at the same time as the host machine, and display status through the embedded web server. You could then have requests come in via the web, and get inserted into the NadaNet network (e.g. by generating an IRQ and having the host machine then poll the control card for the command) I recognise of course that such a solution is going to cost a little bit more than "nada" :-)
Right. I was looking for a simpler solution--in the spirit of NadaNet. ;-) It would be possible to build a "packet router" server to allow NadaNet packets to be sent via the Internet, and response packets to be returned to the Internet for use by another NadaNet machine. This would not, in general, work, since there are strict millisecond- level timing constraints for the acceptable time delays between packets. For some transactions, like &PEEK, it might be necessary not to ACK the first request(s), to allow time to retreive data from the remote machine before accepting the request. For a long data transfer (up to 64KB) this would require both a large buffer and a fairly lengthy latency. (A requester will retry requests that are not ACKed at 20 millisecond intervals for a total of about 6 seconds by default, before reporting a timeout.) Internetworked NadaNets are not a design consideration, so it isn't easy to do. For now, NadaNet is designed as a *local* network for Apple II computers. Of course, it can easily use a "user interface" gateway (as Rich is planning), which is much more tolerant (on both ends) of response delays. In this kind of scheme, the user is a remote user of a local network, and no local network transactions flow across the internet. -michael NadaPong: Network game demo for Apple II computers! Home page: http://members.aol.com/MJMahon/ "The wastebasket is our most important design tool--and it's seriously underused."