Kermit server requirements - Protocols

This is a discussion on Kermit server requirements - Protocols ; We have encountered a problem with an embedded device and I'm thinking Kermit might have my best answer. The device itself is a Pentium 266MHz running Windows 2000. The "control computer" that talks to it in a 486 100MHz running ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: Kermit server requirements

  1. Kermit server requirements

    We have encountered a problem with an embedded device and I'm thinking Kermit
    might have my best answer. The device itself is a Pentium 266MHz running
    Windows 2000. The "control computer" that talks to it in a 486 100MHz running
    Linux.

    Short form is, the device supports ethernet (10 / 100 baseTX) but we can't get
    enough cat-3 or cat-5 cabling between it and the control computer. It's an
    underwater instrument, and the last two feet of waterproof pigtail is straight
    wires, and this is apparently enough to kill the ethernet signalling. I think I
    can solve this by re-wiring the 4 ethernet wires to run into a serial port
    instead. We max at 115200 bps, though, and need to at least get some kind of
    performance on our data transfers.

    I'm considering two options with this serial port. The first is to run a PPP
    server and pretend at the application layer that all is still ethernet. The
    second is to run a Kermit server and issue host commands and file transfer commands.

    I like the Kermit idea because I feel that it will enjoy a significant
    performance gain for file transfers against FTP-via-PPP. The files I need to
    transfer will be in the neighborhood of 4MB each, and I'm still not certain how
    many I'll need to move every day. Coupled with unreliable 3-wire rs232 at
    115200, I think the Kermit protocol will be the fastest thing available and I
    can trust its crash recovery feature better than FTP's. The host commands I
    need to send are rather trivial and the output of them can be parsed easily on
    the control computer.

    So, what do I need to run a Kermit server on Windows 2000? Do any of the free
    versions do it? Can it be set to run as a service, and can I easily verify its
    presence from the control computer? Does it restart itself on crashes, or is it
    so reliable nowadays that I needn't ask the question?

    Finally, is there any good reason I just stick to PPP?

  2. Re: Kermit server requirements

    You need kermit 95.

    It is NOT free, but is cheap. I would not recommend using the trial
    version, the vbox
    encryption is onerous, getting it completely removed is a pain.

    It will not run as a windows service to the best of my knowledge, but is
    easily set up in a host mode.

    I would recommend an autologon enable for this situation, and a startup
    script that invokes kermit w/ the
    desired parameters automatically. It is a simple matter to write a watchdog
    application that restarts kermit
    in the unlikely event of failure.

    a kermit to kermit transfer w/ appropriate tuning will, I believe provide
    quite acceptable performance.



  3. Re: Kermit server requirements

    nospam@killspam.org wrote:
    > You need kermit 95.
    >
    > It is NOT free, but is cheap. I would not recommend using the trial
    > version, the vbox
    > encryption is onerous, getting it completely removed is a pain.
    >
    > It will not run as a windows service to the best of my knowledge, but is
    > easily set up in a host mode.
    >
    > I would recommend an autologon enable for this situation, and a startup
    > script that invokes kermit w/ the
    > desired parameters automatically. It is a simple matter to write a watchdog
    > application that restarts kermit
    > in the unlikely event of failure.
    >
    > a kermit to kermit transfer w/ appropriate tuning will, I believe provide
    > quite acceptable performance.


    You can run k95 with a script as service by using the Microsoft Resource
    Kit tool: SRVANY.EXE

    K95 also comes with the Internet Kermit Service for Windows that runs as
    a native service. Of course, this requires TCP/IP. I could write a
    similar front end service that uses a serial device but it would have to
    be paid for.

    Jeffrey Altman

    --
    -----------------
    This e-mail account is not read on a regular basis.
    Please send private responses to jaltman at mit dot edu

  4. Re: Kermit server requirements

    On 2005-05-26, Kevin L wrote:

    : We have encountered a problem with an embedded device and I'm thinking
    : Kermit might have my best answer. The device itself is a Pentium 266MHz
    : running Windows 2000. The "control computer" that talks to it in a 486
    : 100MHz running Linux.
    :
    : Short form is, the device supports ethernet (10 / 100 baseTX) but we can't
    : get enough cat-3 or cat-5 cabling between it and the control computer. It's
    : an underwater instrument, and the last two feet of waterproof pigtail is
    : straight wires, and this is apparently enough to kill the ethernet
    : signalling. I think I can solve this by re-wiring the 4 ethernet wires to
    : run into a serial port instead. We max at 115200 bps, though, and need to
    : at least get some kind of performance on our data transfers.
    :
    This is quite feasible as long as all the interfaces along the path support
    hardware flow control. But you only have 4 wires - 1 for signal ground,
    1 for receive, 1 for transmit, only one left, which you probably want to use
    for DTR and CD (crossed). So you won't have the best flow control. Second
    best is Xon/Xoff, but that's subject to deadlocks on noisy connections.
    Third best is none at all; let Kermit handle it by regulating the size and
    flow of packets.

    : I'm considering two options with this serial port. The first is to run a
    : PPP server and pretend at the application layer that all is still ethernet.
    : The second is to run a Kermit server and issue host commands and file
    : transfer commands.
    :
    Honestly, I don't know much about the internals of PPP, but TCP and IP,
    which ride on top of it, do not (last time I looked) support such notions as
    sliding windows with selective retransmission. In which case, recovering from
    a transmission error could be much more expensive than with Kermit. But
    without effective flow control, you might not be able to use sliding windows
    in Kermit. It's hard to say without knowing all the facts. Ideally you would
    try each under controlled conditions -- different error rates, etc -- and
    see for yourself.

    : I like the Kermit idea because I feel that it will enjoy a significant
    : performance gain for file transfers against FTP-via-PPP. The files I need
    : to transfer will be in the neighborhood of 4MB each, and I'm still not
    : certain how many I'll need to move every day. Coupled with unreliable
    : 3-wire rs232 at 115200, I think the Kermit protocol will be the fastest
    : thing available and I can trust its crash recovery feature better than
    : FTP's.
    :
    Which you can use as long as the files are transferred in binary mode.

    : The host commands I need to send are rather trivial and the output
    : of them can be parsed easily on the control computer.
    :
    : So, what do I need to run a Kermit server on Windows 2000? Do any of the
    : free versions do it? Can it be set to run as a service, and can I easily
    : verify its presence from the control computer? Does it restart itself on
    : crashes, or is it so reliable nowadays that I needn't ask the question?
    :
    Kermit 95 is not free, but one copy won't break the bank:

    http://www.columbia.edu/kermit/k95order.html

    What you would do, I think, is write a trivial script that sets any desired
    parameters (port, speed, current directory, etc etc) and starts Kermit 95
    server mode (any file whose type is ".ksc" will be executed by Kermit 95).
    This script can then be set up as service with SRVANY:

    http://support.microsoft.com/kb/q137890/

    : Finally, is there any good reason I just stick to PPP?
    :
    PPP, TCP, and IP layers will add a lot more overhead than Kermit. On a
    non-flowcontrolled serial connection they might not work very well, or at
    all. At least with Kermit you can crank the packet length and/or window
    size down to the greatest combination that works reliably.

    - Frank

  5. Re: Kermit server requirements

    My experience w/ SRVANY has been less than stellar but I haven't tried it w/
    kermit in production due to my previous experiences w/ the servany tool...-
    can anyone who is using the combination of this and kermit in a high volume
    or mission critical environment advise of their happiness w/ this
    methodology?


    Frank, Thanks again for your valuable thoughts.



  6. Re: Kermit server requirements

    Frank da Cruz wrote:
    > On 2005-05-26, Kevin L wrote:
    >
    > : We have encountered a problem with an embedded device and I'm thinking
    > : Kermit might have my best answer. The device itself is a Pentium 266MHz
    > : running Windows 2000. The "control computer" that talks to it in a 486
    > : 100MHz running Linux.
    > :
    > : I think I can solve this by re-wiring the 4 ethernet wires to
    > : run into a serial port instead. We max at 115200 bps, though, and need to
    > : at least get some kind of performance on our data transfers.


    > This is quite feasible as long as all the interfaces along the path support
    > hardware flow control. But you only have 4 wires - 1 for signal ground,
    > 1 for receive, 1 for transmit, only one left, which you probably want to use
    > for DTR and CD (crossed). So you won't have the best flow control. Second
    > best is Xon/Xoff, but that's subject to deadlocks on noisy connections.
    > Third best is none at all; let Kermit handle it by regulating the size and
    > flow of packets.


    I've got the machines set up and am running initial tests now. The
    device computer has k95.exe running via SRVANY, the control computer is
    running Linux C-Kermit. All looks well, I'm getting 10,000cps -
    20,000cps on file transfers (binary mode, flow-control none,
    carrier-watch off). However, a few things are strange:

    1. I have to allow k95.exe access to the desktop so I can click through
    the "try" button on the evaluation splash screen. We're almost ready
    with a purchase order (we're another university ) to get a full
    version. Question is: will the purchased no-nag version need to get to
    the desktop too?

    2. The memory usage seems way off. Under taskmgr, k95.exe consumes 14
    megabytes of memory + 5 MB for vbox.dll. Though I know Kermit 95 is a
    superb terminal emulator, I don't need all that function for this use
    case. In general, how can I reduce k95's memory use? More
    specifically, can I execute k95.exe in a "bare-bones" mode ala gkermit?
    I'm ordering the "non-crypto" version, will that eliminate "vbox.dll"?

    3. The CPU requirements are also high: during file transfer from
    C-Kermit to Kermit 95, taskmgr reports k95 as using 95-99% of available
    CPU. Am I doing something wrong? By contrast, the C-Kermit cpu use is
    negligible. One thing that's unusual in my setup: the serial port is
    actually a USB-to-serial bridge.

    In general though Kermit 95 is working out well here. I wish we had a
    few more places to deploy it.

  7. Re: Kermit server requirements

    On 2005-06-09, Kevin L wrote:
    : ...
    : I've got the machines set up and am running initial tests now. The
    : device computer has k95.exe running via SRVANY, the control computer is
    : running Linux C-Kermit. All looks well, I'm getting 10,000cps -
    : 20,000cps on file transfers (binary mode, flow-control none,
    : carrier-watch off). However, a few things are strange:
    :
    : 1. I have to allow k95.exe access to the desktop so I can click through
    : the "try" button on the evaluation splash screen. We're almost ready
    : with a purchase order (we're another university ) to get a full
    : version. Question is: will the purchased no-nag version need to get to
    : the desktop too?
    :
    No.

    : 2. The memory usage seems way off. Under taskmgr, k95.exe consumes 14
    : megabytes of memory + 5 MB for vbox.dll. Though I know Kermit 95 is a
    : superb terminal emulator, I don't need all that function for this use
    : case. In general, how can I reduce k95's memory use? More
    : specifically, can I execute k95.exe in a "bare-bones" mode ala gkermit?
    : I'm ordering the "non-crypto" version, will that eliminate "vbox.dll"?
    :
    Vbox is the nag screen. It was grafted on the K95 by our electronic
    sales and delivery provider, e-academy.com. It's not in the registered
    version at all.

    Various features can be deselected via command-line options, that can
    reduce memory consumption by not loading unneeded DLLs, etc, e.g.:

    -#
    Kermit 95 Startup Flags
    Argument:
    2 - do not load optional network dlls
    4 - do not load optional tapi dlls
    8 - do not load optional kerberos dlls
    16 - do not load optional zmodem dlls
    32 - use stdin for input instead of the console
    64 - use stdout for output instead of the console

    : 3. The CPU requirements are also high: during file transfer from
    : C-Kermit to Kermit 95, taskmgr reports k95 as using 95-99% of available
    : CPU. Am I doing something wrong? By contrast, the C-Kermit cpu use is
    : negligible. One thing that's unusual in my setup: the serial port is
    : actually a USB-to-serial bridge.
    :
    Who knows. Kermit 95 is all threads and semaphores, there are no busy
    loops. It is easy on most CPUs, but every Windows box is different and
    who knows what is lurking behind the windows.

    : In general though Kermit 95 is working out well here. I wish we had a
    : few more places to deploy it.
    :
    Thanks :-)

    - Frank

  8. Re: Kermit server requirements

    1) I warned you about the shareware version Uninstall will not remove
    the vbox crap. You will have to google for vbox removal tools - if you
    can't find one, I may be able to dig up something from the days when I was
    evaling...

    2) I have not run into any situation where k95 was responsible for
    inordinate cpu usage - but I don't run it under the SVRANY scenario -- No
    responses as yet to my queries to the k95 user community about persons using
    k95 / SVRANY in production or high volume environments.



  9. Re: Kermit server requirements

    nospam@killspam.org wrote:
    > 1) I warned you about the shareware version Uninstall will not remove
    > the vbox crap. You will have to google for vbox removal tools - if you
    > can't find one, I may be able to dig up something from the days when I was
    > evaling...


    I agree. The vbox stuff sucks and makes evaluations of the product
    except as an interactive terminal impossible.

    > 2) I have not run into any situation where k95 was responsible for
    > inordinate cpu usage - but I don't run it under the SVRANY scenario -- No
    > responses as yet to my queries to the k95 user community about persons using
    > k95 / SVRANY in production or high volume environments.


    When running under SRVANY you do not want to give K95 access to the
    desktop. In fact, you want to run it without a console. Therefore,
    you should start it with the command line options to force the use of
    stdio. K95 runs just as well under SRVANY as it does on the desktop.
    There are sites that used to use K95 in production in this manner but
    all of them that I am aware of have switched to TCP/IP based connections
    and IKSD.

    Jeffrey Altman
    Kermit 95 Author
    Secure Endpoints Inc.

    --
    -----------------
    This e-mail account is not read on a regular basis.
    Please send private responses to jaltman at mit dot edu

+ Reply to Thread