Network application design

[sagenaut]

The design issue is detailed as following:

One application will write data to a flat file about every hour. Once
the flat file is updated, it must be transmitted to three different
remote locations simultaneously. The requirement is that the three
remote locations must receive the flat file at the same time within a
second, or the transfer was failed, that is, it cannot be that some
locations receive the flat file and the others do not.

What kind of network protocol and interface is best to meet this
requirement to transport a flat file from one location to three
locations simultaneously within a second? Thanks in advance.

[Morris Dovey]

sa******@gmail.com (in
11**********************@n13g2000cwa.googlegroups. com) said:

| The design issue is detailed as following:
|
| One application will write data to a flat file about every hour.
| Once the flat file is updated, it must be transmitted to three
| different remote locations simultaneously. The requirement is that
| the three remote locations must receive the flat file at the same
| time within a second, or the transfer was failed, that is, it
| cannot be that some locations receive the flat file and the others
| do not.
|
| What kind of network protocol and interface is best to meet this
| requirement to transport a flat file from one location to three
| locations simultaneously within a second? Thanks in advance.

This isn't a C language issue. You may find it helpful to ask this
question in news:comp.unix.programmer and, perhaps, to do a web search
and read up on multicast networking.

--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA
http://www.iedu.com/DeSoto

[ozbear]

On 9 Aug 2006 07:25:21 -0700, "sa******@gmail.com"
<sa******@gmail.comwrote:

>The design issue is detailed as following:

One application will write data to a flat file about every hour. Once
the flat file is updated, it must be transmitted to three different
remote locations simultaneously. The requirement is that the three
remote locations must receive the flat file at the same time within a
second, or the transfer was failed, that is, it cannot be that some
locations receive the flat file and the others do not.

What kind of network protocol and interface is best to meet this
requirement to transport a flat file from one location to three
locations simultaneously within a second? Thanks in advance.

I would use tribal drums.

Oz
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[jmcgill]

sa******@gmail.com wrote:

What kind of network protocol and interface is best to meet this
requirement to transport a flat file from one location to three
locations simultaneously within a second? Thanks in advance.

Your time constraints are going to require some kind of feedback, not to
mention clock synchronization. But in general, rsync (over ssl) is what
you are looking for, or looking to reinvent.

[Richard Heathfield]

sa******@gmail.com said:

The design issue is detailed as following:

One application will write data to a flat file about every hour. Once
the flat file is updated, it must be transmitted to three different
remote locations simultaneously. The requirement is that the three
remote locations must receive the flat file at the same time within a
second, or the transfer was failed, that is, it cannot be that some
locations receive the flat file and the others do not.

Reduce your problem. You have a file N bytes in size, where N might be
large. To deliver N bytes to three separate locations within a second of
each other - 3N bytes all told - may not be possible. So break your file up
into two partitions, respectively N-1 bytes and 1 byte in size. Send the
first partition at your leisure, and get confirmation that everyone has it.
Then send the 1-byte partition, and get confirmation for that, with - of
course - a timestamp on it. (Note that, if you get each of the three
confirmations for the second partition within one second of sending, you
don't have to check the timestamps!)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)