[CQ-Contest] Competing in the Daylight - Making it Happen
guy_molinari at hotmail.com
Thu Oct 13 21:21:17 EDT 2005
The reason for multiple boxes (beyond scalability) is for failover in
case a server goes down. This is overkill perhaps for smaller contests, but
for the majors this would probably be prudent.
The reasoning behind HTTP is in that it would sidestep firewall issues. It
would also make it easier to secure. The 'push' side would consist of a
TCP connection that is held open.
Solaris 10 would be nice as it's support for async I/O is superb. Linux
with the e-poll libraries would do almost as well though and it's free.
Could you provide hosting resources? If so, let's take this offline.
Thanks and 73's
>From: Lyndon Nerenberg <lyndon at orthanc.ca>
>To: Guy Molinari <guy_molinari at hotmail.com>
>CC: cq-contest at contesting.com
>Subject: Re: [CQ-Contest] Competing in the Daylight - Making it Happen
>Date: Thu, 13 Oct 2005 12:33:09 -0700
>>I was envisioning a system where there are hooks in logging programs
>>WriteLog, TR-Log, etc.) what would forward log entries to a central web
>>server cluster via HTTP POSTS's.
>HTTP is unnecessary overhead. Updates via UDP will work just fine. In
>fact, this whole thing will run fine on UDP.
>>The other half of this involves a socket push server cluster that would
>>support 100,000 or more live connections.
>Where do you get this 100000 figure from? That seems awfully high.
> > I would need about 3-4 Intel servers
>>running the Linux O/S. I would also need a load balancer (F5, local
>>director) or another server that can function as a load balancer. By
>>clustering 3-4 servers there would be redundancy in case one server
>You should be able to make this work on a single 1GHz P3 Celeron. You're
>trying to make this way more complicated than it needs to be. The two
>critical resources will be sufficient RAM and a reasonably fast network
>stack (for which I would lean towards running this on Solaris 10).
>>2) I would have to write a detailed specification for the logging
>>providers and get their concensus as to how this is implemented.
>All you have to define is the UDP update protocol. This should be very
>simple to do.
>But before setting off to do all of this you need to address a more
>fundamental issue: how are you going to prevent people from sending in
>bogus log entries? You need a security layer for the protocol.
More information about the CQ-Contest