Re: Dynamic C to C Data Transfer

On Sun, 17 Dec 2006 08:15:46 +0000, Richard Heathfield
<rjh@xxxxxxxxxxxxxxx> wrote:

Tom said:

On Sat, 16 Dec 2006 23:33:27 +0000 (UTC),
gazelle@xxxxxxxxxxxxxxxxxxxxx (Kenny McCormack) wrote:

In article <45845237.1596155@xxxxxxxxxxxxxx>,
Roland Pibinger <rpbg123@xxxxxxxxx> wrote:
On Sat, 16 Dec 2006 18:11:49 GMT, Tom wrote:
The scenario is: Several networked machines. Each performing stock
analysis on individual or a small group of financial instruments and
then passing buy/sell instructions to an order placing machine.

Is the platform, by any chance, Windows?
If so, try using INI files. Works real well.

Thanks for the tip Kenny.

It's a tip that doesn't do you any good, though, always assuming your
problem isn't that of opening and writing and reading and closing the
files. For that, any old format will work. But the advice is no more than
we'd expect from Mr McCormack.

The proper way to do this is via sockets, but yes, you could hack at it with
files if you wanted, if you wanted something short-term while you were busy
learning sockets.

Someone suggested starting off in the basement ("00000000.tom"), and writing
each new message in the next file up ("00000001.tom"), with the receiver
deleting as it reads. That sounds workable to me, and doesn't involve the
(easy-to-get-wrong) swapping of two filenames.

Thanks for your incite Richard.

The basement approach to the file naming is very interesting. The
receiving computer could just attempt to open the next sequential file
on a scheduled basis and fail gently if it does not exist. Slick! :)
The receiver deleting prevents filling the drive. Slick again. :))

Certainly sockets is more capable. In the event the receiver is not
available ... the drive space could fill. So the robustness of sockets
is clearly superior. However, there is still that benefit of rotating
between just two (or a few) file names to avoid the drive filling
scenario. My guess is a conflict would eventually surface in the
rotating approach with two machines accessing the same file name. Even
though the receiver would be restricted to read-only privileges. Just
a WAG on my part and experience is needed to go any further in that
evaluation. The sockets approach would be purely memory resident? Thus
the hard drive is not even in the loop and performance is light years
beyond file manipulation? Perhaps add another milliwatt of juice to my
cold light filament. :)

I appreciate everyone's suggestions. Each piece shapes my thinking and
helps start a groove in my totally smooth networking brain cell. Seems
that brain cell is teflon coated at times too. I am starting pursuit
the sockets approach (gulp). This is a daunting task for me. Simply
getting the file transfer working on my two machine network took me
days to figure out. Step-by-step instructions for the task of file
sharing on a LAN (that has been done by tens of thousands of others
and perhaps millions) are amazingly unavailable. Seems those that have
figured it out want to hoard that knowledge and turn providing the
basic instructions into a business all too often.

Classifying the file sharing approach as a short term hack is
"exactly" as it now appears. Earlier I thought it might be elegant.
(The simplest solution that works.) But now it seems to be sprouting
warts all over. Certainly the thinking process to get the hack to work
makes one appreciate the robustness of sockets.

Again, thanks! For reals. :)

-- Tom
.

Relevant Pages

  • Re: Dynamic C to C Data Transfer
    ... then passing buy/sell instructions to an order placing machine. ... This is a problem that just begs for you to use sockets. ... on the client side. ... The subtle gotcha is the data formatting. ...
    (comp.lang.c)
  • Re: sending images over a socket
    ... > A recv() call only returns the data received up to that point. ... > in the sockets implementation, ... > the receiver must fetch this length first, ... > - The sender and receiver always know exactly how much data is transferred ...
    (comp.unix.programmer)
  • Re: reading into the buffer
    ... The behavior isn't specific to BSD sockets. ... The receiver knows it's received the last byte when the shutdown is indicated at the receiver's end returns 0 as the number of bytes read). ... If Receivealways blocked until it'd filled the buffer passed to it, then applications that use the end of the stream to know when the transmission has been completed simply wouldn't work. ... Even changing the API so that it only returned with a partially-filled buffer at the end-of-stream wouldn't make sense, because another valid way of terminating messages is with a delimiter. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Unix Sockets SOCK_DGRAM
    ... I did not found how to send packets via a datagram UNIX sockets? ... this the receiver does not know who we are when using recvfrom. ... fork {# The Parameter Store. ...
    (comp.lang.ruby)
  • Re: IR Hardware Not Detected Error as well
    ... IR Receiver plugged in to the PC to configure if you are using a Set ... (i.e. coax plugged right into the tuner card). ... loft where it is split and fed into various rooms into coax sockets. ... remote is not the official Windows MC hardware but a generic model. ...
    (microsoft.public.windows.mediacenter)