Peter M. Jansson writes: >Why do you think this is too many to use conventional tcp? Isn't one of >the reasons we choose AOLserver that it scales?
The crux of my problem is that I don't have the target hardware yet, and it's quite an experience leap for me to estimate how many requests per second AOLserver can handle on a Sun midframe server for the requests we will be seeing. I believe our systems will be capable of performing thousands of requests per second, but how many thousands? If we have 300 servers and they did something dumb (like our client has demanded/requested) and they each heartbeat each other then each has to handle 300 connections per second just for a heartbeat. And each has to make 300 connections to send its heartbeat to the other systems. That might be a considerable chunk of the max connections a system might handle, and that doesn't include other messages we may wish to pass around involving state information. And none of that includes any of the actual client requests. Now there are various ways we might make this more efficient, but one way that seems to stick out is if we can use some form of broadcast or multicast so that one system can speak to everyone at a time. This would be very nice for heartbeats (as spec'd by the client). It would also seem to make sense for passing state information around as long as we can somehow ensure those multicasts are reliable. By the way, I would love to hear some benchmarks of AOLserver on Sun v100s, v880s, or SunFire 6800s. >You could also consider using DNS to >propagate the data, with caching servers at various points in the network, >assuming you feel the traffic would overwhelm a single server. Can you explain a bit more on how to get DNS to do this? >I don't think multicast is going to work well with HTTP, though, because >HTTP pretty much requires data exchange between broadcaster and receiver, >and multicast pretty much excludes any data from reaching the broadcaster >from the receiver. Yes, well I have thought that I would "break" HTTP in the sense that I wouldn't be returning any responses back. On the other hand I would love to hijack the request processor so that I can operate on a multicasted HTTP get/post. And what I would probably do to start out is have each multicast include a sequence number and have clients have a reverse request so that they can keep track themselves of which messages they didn't receive and ask to have those retransmitted. Yes it's kludgey, that's why I would appreciate hearing from anyone that has looked into "reliable ip multicasting". >I'm curious to find out what you learn, though. >Pete. I'll be happy to follow up if anything interesting comes along. Jerry
