On Fri, 11 Oct 2002, Dossy wrote: > During times of heavy traffic, you might lose some packets. But, > is that critical? From the sounds of it, probably not.
Good point. If it is critical that every, then the Swiss Army Knife might not be right choice. You would probably be better served by having a dedicated daemon that maintained an open TCP connection to each other host, and then they exchange status over the open connection. TCP would provide the reliability you need, and maintaining open connections would provide the least latency. The daemon could update a scoreboard in memory that was mmap-ed to a file so other things could read it. If you use HTTP, you'll either have connection setup and teardown on each request (unless you use keepalive, but how long to maintain the connection? and AOLserver keepalive parameters are specified on a per-server basis, not a per-client basis), and you'll have the roundtrip latency. If you use a TCP virtual circuit, then host x can just write its status down the pipe to host y and not worry about obtaining a response. You can process stuff much more quickly that way. (Although I still think stratifying the data is a better long-term bet.)
