diverting from screen to file

Discussion in 'Perl Misc' started by cartercc, Sep 17, 2008.

  1. cartercc

    cartercc Guest

    This may be totally off base, but it's a problem I currently face, and
    I don't know where to start. It's not necessarily a Perl problem, but
    it seems like something that Perl was designed to handle (at least in
    theory).

    I have a remote application that is a data source but not a RDBMS. I
    have a local GUI client that connects with the remote application. I
    can use the local client to type in 'queries' which the client relays
    to the remote application and displays the results to the screen.
    Unfortunately, this is entirely transient and I don't have any means
    given by the client to save the results to a file. When I close to
    client, there's nothing left on my machine.

    I would like to divert the stream coming in from the remote
    application to a file. I can confirm that the results are what I want
    and then rerun the 'query' to reproduce the results, but I need to
    have some persistency. The data does reach my local machine, but I
    don't know how to keep it. Any suggestions on where I should start?

    The client is an .exe file, and all I know how to get from trying to
    read the client is an OD of the code. I even tried to disassemble it
    and all I got was an unreadable mess.

    TIA, CC.
    cartercc, Sep 17, 2008
    #1
    1. Advertising

  2. Re: GG diverting from screen to file

    cartercc wrote:
    > This may be totally off base, but it's a problem I currently face, and
    > I don't know where to start. It's not necessarily a Perl problem, but
    > it seems like something that Perl was designed to handle (at least in
    > theory).
    >
    > I have a remote application that is a data source but not a RDBMS. I
    > have a local GUI client that connects with the remote application. I
    > can use the local client to type in 'queries' which the client relays
    > to the remote application and displays the results to the screen.
    > Unfortunately, this is entirely transient and I don't have any means
    > given by the client to save the results to a file. When I close to
    > client, there's nothing left on my machine.
    >
    > I would like to divert the stream coming in from the remote
    > application to a file. I can confirm that the results are what I want
    > and then rerun the 'query' to reproduce the results, but I need to
    > have some persistency. The data does reach my local machine, but I
    > don't know how to keep it. Any suggestions on where I should start?
    >
    > The client is an .exe file, and all I know how to get from trying to
    > read the client is an OD of the code. I even tried to disassemble it
    > and all I got was an unreadable mess.
    >


    Ideas:

    1) Use wireshark to capture the data. I often find it's "follow TCP
    stream" feature is useful.

    2) Create a proxy that sits between the client and server and which
    captures the data you want to "persist". This might be a Perl program or
    it might be something like socat.

    http://www.dest-unreach.org/socat/doc/socat.html

    -v
    Writes the transferred data not only to their target streams, but
    also to stderr. The output format is text with some conversions for
    readability, and prefixed with "> " or "< " indicating flow
    directions.

    ...

    socat TCP4-LISTEN:www TCP4:www.domain.org:www

    Installs a simple TCP port forwarder. With TCP4-LISTEN it listens on
    local port "www" until a connection comes in, accepts it, then
    connects to the remote host (TCP4) and starts data transfer. It will
    not accept a second connection.

    The docs contain examples for forking proxies and all sorts of
    potentially useful options.


    --
    RGB
    RedGrittyBrick, Sep 17, 2008
    #2
    1. Advertising

  3. cartercc

    Jim Gibson Guest

    In article
    <>,
    cartercc <> wrote:

    > This may be totally off base, but it's a problem I currently face, and
    > I don't know where to start. It's not necessarily a Perl problem, but
    > it seems like something that Perl was designed to handle (at least in
    > theory).
    >
    > I have a remote application that is a data source but not a RDBMS. I
    > have a local GUI client that connects with the remote application. I
    > can use the local client to type in 'queries' which the client relays
    > to the remote application and displays the results to the screen.
    > Unfortunately, this is entirely transient and I don't have any means
    > given by the client to save the results to a file. When I close to
    > client, there's nothing left on my machine.
    >
    > I would like to divert the stream coming in from the remote
    > application to a file. I can confirm that the results are what I want
    > and then rerun the 'query' to reproduce the results, but I need to
    > have some persistency. The data does reach my local machine, but I
    > don't know how to keep it. Any suggestions on where I should start?
    >
    > The client is an .exe file, and all I know how to get from trying to
    > read the client is an OD of the code. I even tried to disassemble it
    > and all I got was an unreadable mess.


    Your choices would seem to be: 1. modify the client to save data, 2.
    modify the server to save data, or 3. put a "proxy" between the client
    and the server.

    If you can't do 1. or 2., then 3. is your only hope. Do you know the
    protocol that the client uses to communicate with the server? If so,
    you write a proxy program that looks like a server to the client and
    looks like a client to the server, and it passes data requests from the
    actual client to the actual server, and passes back the responses from
    the actual server to the actual client.

    If you don't know the protocol, then you can try to reverse engineer it
    using some sort of packet sniffer, presuming that the communications
    protocol is TCP/IP-based. Or you just use a packet sniffer, such as
    tcpdump, to record all traffic between the client and server and figure
    out how to extract the pertinent data.

    This is not an enviable task. If the client/server protocol is a
    proprietary one, it might even violate the terms-of-use to which you
    have agreed.

    Good luck!

    --
    Jim Gibson
    Jim Gibson, Sep 17, 2008
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Russell
    Replies:
    1
    Views:
    364
    Steve C. Orr [MVP, MCSD]
    Jan 21, 2004
  2. Pat
    Replies:
    5
    Views:
    523
  3. owl
    Replies:
    2
    Views:
    858
  4. Biranchi Narayan Panda
    Replies:
    1
    Views:
    2,706
    Alexey Smirnov
    Feb 17, 2010
  5. Nairb

    screen.height vs. screen.availHeight

    Nairb, Jul 2, 2003, in forum: Javascript
    Replies:
    0
    Views:
    104
    Nairb
    Jul 2, 2003
Loading...

Share This Page