E-Kermit Ｈｐの訳

E-Kermit HomePageの訳
Version: 1.7
Date: 6 June 2011

有限会社　富士設計
http: //www.d1.dion.ne.jp/~fujisekk/
http://homepage3.nifty.com/fujisekk/
TEL 042-323-2217

@nifty翻訳を使用
　おかしい所を修正
段落ごとに訳してはいるが、区切りのよいところで分けている
訳が無くてもわかる所は訳していない。
注意！このページを利用した結果についてなんらのの保障をするものではない。

What E-Kermit DoesEK (Embedded Kermit, E-Kermit) is an implementation of the Kermit file transfer protocol written in ANSI C and designed for embedding in devices or firmware, use in realtime applications, or for construction of DLLs and libraries. EKSW is a new version of E-Kermit that includes true sliding windows packet transport. EK and EKSW should be reconciled back into a single code base but so far that has not happened.

EK(組み込みカーミット、E-カーミット)は、ANSI Cに書かれて、デバイスかファームウェアへのみ込み、リアルタイムアプリケーション、またはDLLsの構造の使用、およびライブラリに設計されたカーミットファイル転送プロトコルの実現です。
EKSWは、本当のスライディングウィンドウパケット輸送を含んでいるE-カーミットの新しいバージョンです。 EKとEKSWはただ一つのコードベースに和解して戻るべきですが、今までのところ、それは起こっていません。

EK performs just two functions: sending files and receiving files. It is compact, portable, and fully reentrant. On SPARC (RISC), kermit.o is about 25K. On Intel (CISC) it's about 15K. By reducing buffer sizes and eliminating optional or unwanted features, smaller sizes can be achieved.
EK はちょうど2つの機能を実行します: ファイルの受信、送信。それは、完全にコンパクトであって、移動容易でリエントラントです。
SPARC(RISC)の上では、kermit.oは約25Kです。インテル(CISC)では、それは約15Kです。バッファサイズを減少させて、任意の、または、求められていない特徴を取り除くことによって、より小さいサイズを達成できます。

EK does not include client/server functions; a command or script programming language; character-set conversion; transport encryption; or any form of communications or file input/output. It does not dial modems, it does not make connections, it does not have a built-in TCP/IP stack or interface to an external one. If you need these features, then you should use a full Kermit program, such as C-Kermit or Kermit 95

EKはクライアント/サーバ機能を含んでいません。コマンドかスクリプトプログラミング言語。文字集合変換。輸送暗号化。または、コミュニケーションかファイル入力/出力のどんなフォーム。それには、それはモデムにダイヤルしないで、また接続を作らないで、また内蔵のTCP/IPスタックかある外部へのインタフェースもありません。
これらの特徴を必要とするなら、あなたはC-カーミットかカーミット95などの完全なカーミットプログラムを使用するべきです。

EK is not an application itself, it's a subroutine to be called from your master application. It is useful only to developers, who must supply the master application or calling environment as well as the file and communications i/o routines. The calling environment must, in turn, make and configure the communications connection if one is required and not already open. A sample calling environment and i/o support are provided for Unix.

EKはアプリケーション自体ではありません、あなたのマスターアプリケーションから呼ばれるサブルーチンです。
それは、開発者だけの役に立つかファイルやコミュニケーションと同様に環境を入出力ルーチンと呼びます。
(その開発者は、マスターアプリケーションを供給しなければなりません)。
1つが必要であって、既に開かないなら、呼び出し環境は、順番にコミュニケーション接続を作って、構成しなければなりません。
Unixのサンプル呼び出し環境と入出力サポートをに提供します。

Customers have adapted EK to various environments and platforms, including the Palm Pilot, various kinds of technician equipment (e.g. for diagnosis and maintenance of cell phone towers), and sometimes they contribute their adaptations or i/o routines, and we can make these available on a strictly as-is basis. We are not able to support or maintain customer-contributed code; thus (for example) if a new version of EK is released, customer-contributed modules are not necessarily updated. Customer-contributed code includes:

    Microsoft Windows 9x/ME/NT/2000/XP/Vista/7 serial-port and file i/o for EK 1.3 and later.
    Wind River VxWorks for EK 1.1.
    EK 1.2 translated into Java.
EK includes the following Kermit Protocol features:

    Long packets
    Sliding windows with Go-Back-to-N error recovery (true selective repeat in EKSW).
    Repeat-count compression
    Control-character prefixing and unprefixing
    8th-bit prefixing (for transferring 8-bit data on 7-bit links) (= parity)
    Attribute packets (type, size, and date)
    Sending and receiving single or multiple files.
    Automatic per-file text/binary mode switching.
    All three block check types (6- and 12-bit checksum, 16-bit CRC).
    Status reports (protocol state, file name, size, timestamp, bytes so far).
    Transfer cancellation by either party.

顧客は様々な環境とプラットホームにEKを適合させました、パームパイロットを含んでいます、様々な種類の技術者設備(例えば、携帯電話塔の診断とメインテナンスのために)、
そして、時々、彼らの付加機能か入出力ルーチンを寄付します、そして、私たちが利かせることができる、これら、利用可能である、オンである、厳密にそのままである私たちは、顧客によって寄付されたコードをサポートできませんし、維持できません。
したがって、(例えば)、EKの新しいバージョンをリリースするなら、必ず顧客によって寄付されたモジュールをアップデートするというわけではありません。顧客によって寄付されたコードは:

THE CONTROL PROGRAM

EK is designed to work in a cooperative multitasking environment but does not require such an environment. The control program takes care of scheduling. Here's what the control program must (and/or can) do:

    If desired, open the communications device, if any.
    If desired, put the communications device, if any, into "packet mode".
    Initialize the kermit struct with desired operating parameters.
    Call kermit(K_INIT, ...) to have Kermit initialize itself.
    If sending files, call kermit(K_SEND) to start the transfer.

EKは協調的マルチタスク環境で働くように設計されていますが、そのような環境を必要としません。
制御プログラムはスケジューリングの世話をします。以下に、制御プログラム(and/or can)がやらなければいけないものがあります:
要求があれば、もしあればコミュニケーションデバイスを開けてください。
要求があれば、もしあれば「packet mode」にコミュニケーションデバイスを設定してください。
希望の運転パラメータがあるカーミットstructを初期化してください。
カーミット(K_INIT、…)を呼び出して、カーミットにそれ自体を初期化させてください。
ファイルを送るなら、カーミット(K_SEND)を呼び出して、転送を始めてください。

(When E-Kermit is to receive files, it waits passively for first packet from the file sender; thus it simply enters the packet loop.) In the packet loop, E-Kermit:

    Gets a buffer and reads an incoming packet into it.
    Checks for user interruption.
    Calls kermit(K_RUN, ...) to do the next step in the protocol.
    Does whatever else it wants (e.g. runs other tasks).
    Quits or continues the loop based on the kermit() return code.

E-カーミット、パケットループ
(E-カーミットがファイルを受け取ることになっているとき、ファイル送付者から最初のパケットを受け身で待っています; その結果、単なるパケットループに入る。)

バッファを得て、それから入って来るパケットを読み取ります。
ユーザによる中断のためのチェック。
プロトコルにおける次のステップをするためにカーミット(K_RUN、…)を呼び出します。
必要な(例えば、他のタスクを走らせます)他のことをします。
カーミット復帰コードに基づきループ、やめるか、または続けています。

Each time the control program calls the kermit() function, this grants it permission to handle one packet; thus one packet = one time slice. If the control program has nothing else to do, it simply processes packets continuously, like a regular Kermit program. While in the data-transfer loop, every kermit() call returns a struct containing:

    The current protocol state;
    The current filename;
    The file's size, if known, or -1;
    The file's timestamp, if known;
    The number of bytes transferred so far.

制御プログラムがカーミット()機能を呼ぶたびにこれは1つのパケットを扱う許可をそれに与えます、1つのパケット=一定時間にがあるとき。
制御プログラムに他に何もすることががないなら、それは連続的なカーミットプログラムのように単に絶え間なくパケットを処理します。
データ転送ループにある間、あらゆるカーミット呼び出しが以下の事項を含むstructを返します。

現在のプロトコル状態。
現在のファイル名。
わかっているファイルのサイズ、または-1。
わかっているファイルの、タイムスタンプ。
今までの転送バイト数。

When done, the control program
Restores and (if desired) closes the communications device.
制御プログラムが終了したら:
回復して、コミュニケーション装置を閉じます(必要なら)。

The function codes that the control program may call kermit() with are:
    K_INIT   -- Initialize data structures.
    K_SEND   -- (Sending only) -- Initiate sending.
    K_RUN    -- Run the protocol.
    K_STATUS -- Return a status report in the k_response struct.
    K_QUIT   -- Quit immediately and silently.
    K_ERROR -- Send Error packet, then quit.

制御プログラムがカーミット()と呼ぶかもしれない機能コードがあります:
    K_INIT   -- データ構造を初期化
    K_SEND   -- (Sending only) -- 発信を開始
    K_RUN    -- Run the protocol.
    K_STATUS -- k_response構造体で現状報告を返.
    K_QUIT   -- Quit immediately and silently.
    K_ERROR -- Errorパケットを送信、そして終了。

The return codes of the kermit() function are:
    X_OK     -- OK, protocol active.
    X_DONE   -- OK, protocol complete.
    X_ERROR -- Fatal error.
    X_STATUS -- Returning status in response to K_STATUS.

カーミット()機能の復帰コードは以下の通りです。
    X_OK     -- OK, protocol active.
    X_DONE   -- OK, protocol complete.
    X_ERROR -- Fatal error.　致命的な誤り
    X_STATUS -- Returning status in response to K_STATUS. K_STATUSに対応して状態を返します　下記参照。

(In fact status is retuned with every call.) Protocol state codes are:
　(状態はあらゆる呼び出しのときに再設定されます。) プロトコルステートのコードです。

    -1       -- Fatal error
     0       -- Receiver (protocol not running)
     1       -- Receiver waiting for S packet
     2       -- Receiver waiting for F or B packet
     3       -- Receiver waiting for A or D packet
     4       -- Receiver waiting for D or Z packet
    10       -- Sender (protocol not running)
    11       -- Sender sent S packet (start)
    12       -- Sender sent F packet (filename)
    13       -- Sender sent A packet (attributes)
    14       -- Sender sent D packet (data)
    15       -- Sender sent Z packet (EOF)
    16       -- Sender sent B packet (EOT)

FILE TRANSFER

Because EK is designed primarily for embedding, it does not use streaming or true sliding windows (although much of the sliding windows code is there). This is for the following reasons:
EKが主として組み込むことのために設計されているので、それはストリーミングの、または、本当のスライディングウィンドウを使用しません(スライディングウィンドウコードの多くがそこにありますが)。これは以下の理由であります:

スライディングウィンドウプロトコル: ウィンドウの範囲内で確認応答を待たずに複数のデータを並列的に送信するプロトコル (略: SWP).

Using the regular ACK/NAK protocol allows the control program to regain control after every packet. This lets it multitask, put up a graphical file-transfer display, whatever. Streaming or sliding windows could put the control program out of business for long periods of time.

通常のACK/NAKプロトコルを使用するのに、制御プログラムはあらゆるパケットの後にコントロールを取り戻すことができます。これで、グラフィカルなファイル転送ディスプレイに置かれて、それは何でもマルチタスキングします。ストリーミングの、または、スライディングウィンドウは長期間の間、廃業している制御プログラムを置くかもしれません。

Streaming or true sliding windows would make the interface between the control program and the kermit() module much more complicated, and in fact, would push a lot of protocol details into the control program's space, where they don't belong.

ストリーミングの、または、本当のスライディングウィンドウで制御プログラムとカーミットモジュールの間のインタフェースははるかに複雑になるでしょう、そして、多くのプロトコルの詳細を制御プログラムのスペースに押し込むでしょう。それでは、それらが成り立ちません。

Streaming can be used only on reliable connections (such as TCP/IP) but devices with embedded communications generally use serial ports

単に頼もしい接続(TCP/IPなどの)のときにストリーミングを使用できますが、一般に、組み込コミュニケーションではデバイスはシリアルポートを使用します。

The lack of true sliding windows in EK is compensated by having EK pretend to support them without really doing so. This allows its sending partner to "stream" packets rather than waiting for ACKs after each one, as long as there isn't an error. If there is an error, the recovery strategy is "go back to n" (or perhaps in some cases "error out") rather than "selective repeat". EKSW, a separate program that has not been integrated with EK (but should be), supports true sliding windows with selective repeat; that is, only those packets are retransmitted that actually need to be.

EKに本当にそうせずにそれらをサポートするふりをさせることによって、EKの本当のスライディングウィンドウの不足を代償します。
これは、送付パートナーがそれぞれ後にACKsを待つよりむしろパケットを「流すこと」を許容します、誤りがない限り。
誤りがあれば、回復戦略は「選択している反復」よりむしろ「nに戻る」(またはおそらくいくつかのケース「誤りアウト」で)です。
EKSW(EK(しかし、あるべきである)について統合していない別々のプログラム)は選択している反復で本当のスライディングウィンドウをサポートします。すなわち、実際にそれが必要があるならそれらのパケットは再送されるだけです。

in any event, since EK is intended primarily for embedding, it is anticipated that round-trip delays won't be a big factor; connections will generally be local, short, relatively fast, and if the connection is effectively flow controlled, error-free. When effective flow control is lacking, the speed and/or packet length and/or window size can be set to a combination of values that maximizes throughput and minimizes data loss.

とにかく、EKが主として組み込むことのために意図するので、往復の遅れが大きい要素にならないと予期されます。一般に、接続が急に比較的速く、近くの接続であれば、事実上流れるのは、制御されていて、エラーが無い?
効果的なフロー制御が欠けているとき、スループットを最大にして、データの損失を最小にする値の組み合わせに速度、パケット長、そして/またはウィンドウのサイズを設定できます。

SOURCE CODE
The source files are:

platform.h
Header file for any needed platform-specific #includes or definitions. Required, even if it's empty, because kermit.c includes it.

kermit.h
    Header file for all modules. Definition of k_data and k_response structs.
kermit.c
This is the Kermit protocol engine. It is driven entirely by its call data. All state info is saved in the kermit data structure, which is passed by reference from the main module and among all the functions in the kermit module and back again to the main module; thus it should be possible for the same module to transfer multiple files at once on different connections. Furthermore, there are no library references in the kermit module, none at all, not even stdio (except when debugging is enabled), and no /usr/include/* header files are included. Rules for kermit.c:

これはカーミットプロトコルエンジンです。それは呼び出しデータによって完全にドライブされます。すべてのステートのインフォメーションがカーミットデータ構造で保存されます。(それは、カーミットモジュールで行き帰りメインモジュールに主なモジュールとすべての機能の中の参照で通過されます)。
したがって、同じモジュールが異なった接続のときに複数のファイルを移すのは、可能であるべきです。
その上、カーミットモジュールによるライブラリー参照が全くありません、stdio(デバッグが可能にされる時を除いた)のすべてさえ、そして、どんな /usr/include/*ヘッダーファイルも含まれていません。
kermit.cのための規則:

    No global variables (except for debugging) or buffers.
    No initializing of arrays by compiler.
    Just for safety, no initializing automatic scalars either.
    No library or system calls, no #include <...>.
    All communications i/o is done by functions defined in separate modules.

大域変数(デバッグを除いた)でないバッファがありません。
コンパイラによるアレイを初期化しないこと。
まさしく安全なように自動スカラを初期化しない。
ライブラリがないシステムコール、どんな#も<を含んでいません…>.
はすべてのコミュニケーション入出力は別々のモジュールで定義された機能で実現します。

The single entry point for the kermit.c module is the kermit() function:

    int kermit(struct k_data * k, struct k_response * r)

The k structure contains all the operating parameters, variables, state information, and buffers;
the r struct keeps the caller informed of the current state of the protocol, filename and file info, and transfer progress (bytes so far).
k構造体はすべての運転パラメータ、変数、ステートの情報、およびバッファを含んでいます。
r 構造体は、コーラーがプロトコルのステート、ファイル名、およびファイルインフォメーションの現状において知識がある、および転送数(今までのところのバイト)であることを保ちます。

main.c
Sample control program. In the Unix testbed, this is just the traditional main(), which reads command-line arguments, initializes the protocol, then calls the protocol module in a state-driven loop until its work is done, then cleans up. In the embedded environment, these functions would be integrated into the control program.

サンプル制御プログラム。
Unixテストベッドでは、これはただ伝統的なメイン()です、コマンドライン議論を読んで、
プロトコルを初期化して、次に仕事が完了して、クリンアッフするまで状態駆動の輪のプロトコルモジュールをコールする。
組み込み環境では、これらの機能は制御プログラムに統合されるでしょう。

unixio.c
I/O functions for Unix. Substitute your own module that implements these functions in the target environment and modify your build procedure to link with it. Entry points and calling conventions described below.

I/OはUnixのために機能します。標的環境におけるこれらの機能を実装するあなた自身のモジュールを代用してください、そして、それにリンクするようにビルド手順を変更してください。
エントリー・ポイントと以下で説明された呼び出し規則。

THE UNIX VERSION
Development of EK takes place on a conventional Unix platform, such as Solaris, HP-UX, or Linux, in which EK is built as a remote-mode Kermit file transfer program, similar to G-Kermit, and tested against a desktop Kermit such as K95 or C-Kermit. NOTE: The Unix version works over stdin/stdout; the "line" is conditioned in the stupidest possible way (system("stty ...")). This gives variable results; e.g. downloads from EK on Solaris might run at 17Kcps, whereas downloads from Linux on the same net to the same PC might run at 1700Kcps. This is not worth worrying about because EK is not intended for production use on Unix, which already has G-Kermit and C-Kermit for production.

EKの開発はSolaris、HP-UX、またはリナックスなどのような従来のUnixプラットホームで行われます。
(EKはG-カーミットと同様のリモートモードカーミット・カーミットファイル転送プログラムとして造られ、
デスクトップK95かC-カーミットに対してテストされます)。
注意: Unixバージョンはstdin/stdoutの上で働いています。
「系列」は可能な限り愚かな方法(システム("stty"…))で条件とします。これは可変結果を与えます; 例えば、Solarisの上のEKからのダウンロードは17Kcpsで稼働していますが、同じネットのリナックスからPCまでのダウンロードは 1700Kcpsで稼働するかもしれません。
EKがUnixにおける生産使用のために意図しないので、このことは心配する価値がありません。既に、Unixは生産のためのG-カーミットとC-カーミットがいます。

The Unix makefile has the following targets (it's easy to add more):
Unixメイクファイルには、以下のターーゲットがあります(もう少し加えるのは、簡単です)。
gcc:   Build with gcc (default).
cc:    Build with cc.
hp:    Build for HP-UX.
gccnd: Build with gcc, no debugging.
gprof: Build with gcc, include profiling.
clean: Remove object and core files.

The makefile creates a Unix executable called "ek" (embedded kermit). The sample main() routine provides a simple command-line interface:

メイクファイルはUnix実行可能な"ek"呼とばれる(組み込まれたカーミット)を作成します。
サンプル　メイン()ルーチンは簡単なコマンドラインインタフェースを提供します:

$ ./ek -h
Usage: ./ek options
Options:
-r           Receive files
-s files     Send files
-p [neoms]   Parity: none, even, odd, mark, space
-b [123]     Block check type: 1, 2, or 3 (default = 3)
-k           Keep incompletely received files
-B           Force binary mode
-T           Force text mode
-R           Remote mode (vs local)
-L           Local mode (vs remote)
-E number    Simulated error rate (0-100)
-d           Create debug.log
-h           Help (this message)
$

When sending files, if you don't specify Text or Binary, EK scans each file and chooses text or binary mode based on its contents.

ファイルを送るとき、あなたがTextかBinaryを指定しないなら、EKは各ファイルをスキャンして、コンテンツに基づくテキストかバイナリ・モードを選びます。

Remote vs Local mode is used only to enable the test for keyboard interruption of file transfer.
Localに対してリモートモードを使用すると、ファイル転送のキーボード中断のためのテストを可能にします。

PORTING TO A NEW PLATFORM

Version 1.0 of EK was ported to VxWorks by Airvana, Inc, Chelmsford MA. The complete VxWorks EK 1.1 package is included as an example of a production system by Airvana's permission (note that the EK API has changed slightly since then, so before the VxWorks code can be used, it must be updated). To port to a new platform:

EKのバージョン1.0はAirvana、Inc、チェルムズフォードMAによってVxWorksに移植されました。
新しいプラットホームに移植するために
完全なVxWorks EK1.1パッケージはプロダクションシステムの例としてAirvanaの許可によって含まれています(VxWorksコードを使用できる前に、それをアップデートしなければならないためにEK APIがわずかにそれ以来変化していることに注意してください)。

Add a new Makefile entry for your target, or write your own build procedure.
ターゲットのために新しいMakefileエントリーを加えるか、またはあなた自身のビルド手順を書いてください。

Create a platform.h file for your platform. This can include any desired #include's or definitions, and it can also be used to override certain definitions in kermit.h

#define NODEBUG to build without debugging code.
#define HAVE_UCHAR if UCHAR is already defined or typedef'd to unsigned char.
UCHARが既に定義されるかどうか、typedefはunsigned charのようにするでしょう。
#define HAVE_ULONG if ULONG is already defined or typedef'd to unsigned long.
ULONGが既に定義されるかどうか、typedefはunsigned longのようにするでしょう。
#define IBUFLEN to be the desired size for the file input buffer.
ファイルのための希望のサイズであるIBUFLENは入力バッファをしました。
#define OBUFLEN to be the desired size for the file output buffer.
ファイルのための希望のサイズであるOBUFLENは出力バッファをしました
#define FN_MAX to be the maximum length for a filename.
FN_MAX　ファイル名のための最大の長さ
#define P_PKTLEN to override the default maximum packet length.
デフォルトの最大のパケット長をP_PKTLENで置き換える。
#define P_WSLOTS to override the default maximum window slots.
デフォルトのmaximum window slotsP_WSLOTSで置き換える。

プラットホームのためのplatform.hファイルを作成してください。
これはどんな希望の#include's ものや定義も含むことができます、そして、また、kermit.hの定義をくつがえすのにそれは使用できます。

Replace the sample main.c with your own control program. Use the same header files and calling conventions as in the sample.

サンプルmain.cをあなた自身の制御プログラムに取り替えてください。サンプルのように同じヘッダーファイルと呼び出し規則を使用してください。

Copy unixio.c to xxxio.c (name of your choice), edit it to work on your platform using exactly the same calling conventions, and adjust your build procedure to link with your new xxxio module instead of unixio. Note that the fill input and output buffers (i_buf[] and o_buf[]) must be defined in your xxxio routine.

xxxio.c(あなたの選択の名前)にunixio.cをコピーしてください、そして、あなたのプラットホームで働くためにまさに同じ呼び出し規則を使用することでそれを編集してください、そして、unixioの代わりに新しいxxxioモジュールとのリンクに体格手順を調整してください。
Note　入出力バッファ(ii_buf[] and o_buf[]) 、あなたのxxxioルーチンで定義しなければなりません。

Here are a few tips for creating an i/o module
ここに、入出力モジュールを作成するためのいくつかのチップがあります。

The device i/o routines are expected to handle communications parameters themselves, including communication line speed, parity, and flow control. In particular, Kermit does not handle parity, but still must be told about it. This is done in the setup by main(). Your readpkt() and tx_data() routines should strip and add parity, respectively, if necessary. On serial connections, maybe the UART can be programmed to do this.

通信回線速度、およびフロー制御を含んでいて、装置入出力ルーチンがコミュニケーションパラメタ自体を扱うと予想されます。
カーミットについて特に、同等を扱いませんが、それに関してまだ話さなければなりません。
メイン()はセットアップでこれをします。必要なら、あなたのreadpkt()とtx_データ()ルーチンは、パリテイを取たり、加えるべきです。
たぶん、連続の接続のときに、UARTがこれをするようにプログラムできます。

The device i/o functions are
int
devopen(char * device)
    Opens the given communications device. Might also be a network host, whatever. Returns 0 on failure, 1 on success.
特定のコミュニケーションデバイスを開けます。また、すべてのネットワークホストになるかもしれない。
リターン失敗0、成功1。

int
devsettings(char * settings)
    This one performs any needed settings for the device, such as speed and flow control for a serial device. Since there's no way to know what the relevant parameters are, this routine just takes a string, which can be in any format, e.g. "9600;8N1" or "speed=57600;flow=rts/cts"; the devsettings routine will have to parse the string. Returns 0 on failure, 1 on success.

    これは装置のために、シリアルデバイスのために速度やフロー制御などのどんな必要な設定も実行します。
または、関連パラメータが何であるかを知る方法が全くないので、このルーチンがどんな形式のストリングを取るということであるかもしれない、例えば「9600、; 8N1、」、「speed=57600;flow=rts/cts」と等しいです。
devsettingsルーチンはストリングを分析しなければならないでしょう。
リターン失敗0、成功1。

int
devrestore(void)
    If desired, put device back the way devsettings() found it, e.g. just before closing it.
望まれているなら、デバイスを戻す方法を置いてください、例えばそれを閉じるすぐ前にdevsettings()がそれを見つけた方法で

int
devclose(void)
    Closes the communications device.

int
readpkt(UCHAR * buffer, struct k_data * k) (1.1)
readpkt(struct k_data * k, UCHAR * buffer, int length) (1.2)

This routine must do exactly what the sample one does: search for the start of packet, then copy all the characters up to (but not including) the end of packet into the packet buffer whose address is given. You'll want to code this as efficiently as possible, using whatever tricks are available to you: nonblocking buffered reads, etc. If you want your Kermit program to time out, this is where you would put the code. NOTE: Timeouts are not necessary, since the chances that ek's Kermit partner can not time out are about 0. The EK 1.2 format puts k as the first argument for consistency with other routines, and adds a buffer length argument.
このルーチンはまさにサンプル1がすることをしなければなりません:
パケットの始まりの検索、アドレスが与えられているパケットバッファの中へのパケットの(しかし、包含しない)端までのすべてのキャラクタを、その時、コピーします。
あなたにとって、利用可能などんなトリックも使用して、あなたはできるだけ効率的にこれをコード化したくなるでしょう:
ノンブロックバッファリングは読込みなどあなたがカーミットプログラムがタイムアウトに欲しいなら、これはあなたがコードを置くところです。
注意: タイムアウトではなく、ekのカーミットパートナーがそうすることができる機会が、約0であるので、タイムアウトは必要ではありません。
EK1.2形式は、一貫性のための他のルーチンとの最初の議論としてkを置いて、バッファ長議論を加えます。

Note the F_CTRLC feature. This is enabled by default. It allows EK to be broken out of packet mode by sending it three consecutive Ctrl-C's in the data stream. You normally would not need to disable this since, even if the sender is "unprefixing" Ctrl-C, three of them in a row would normally be collapsed into a repeat-count sequence.

F_CTRL　Cの特徴に注意してください。これはデフォルトで可能にされます。
それは、EKがデータストリームに　Ctrl-Cを３個送ることによるパケットモードから脱出するのを許容します。
送付者が"unprefixing"であってもCtrl-C(それらの3つは並んでいる)が通常repeat-count sequenceまで潰されるでしょうから、通常、あなたはこれを無効にする必要はないでしょう。

int
tx_data(UCHAR * data, int length, short parity) (1.1)
tx_data(struct k_data * k, UCHAR * data, int length) (1.2)

Here again, you must tack on parity (if it is not being done automatically by the communication device or driver). This routine should be both efficient and robust. It is supposed to transmit the entire data string or else fail. See the unixio.c sample for what I mean by "robust". In EK 1.2 and later, the parity setting is picked up from the k struct.

一方、ここに、あなたはパリテイを付加しなければなりません(通信装置かドライバーが自動的にそれを完了していないなら)。このルーチンは、効率的であって、かつ強健であるるべきです。全体のデータ列を伝えるべきであるか、またはそれは失敗するべきです。
私が「強健」で言っていることのためのunixio.cのサンプルを見てください。 EK1.2とその後、パリティ設定はk構造体から拾われます。

The file i/o functions are as follows; of course they can be used for reading or writing anything -- not just files: memory, tape, cards, laser beams, instrument controllers, whatever. It doesn't matter what you call these routines, but the argument list and return type must be as shown; also if you give them different names, you'll have to change the prototypes in kermit.h:
ファイル入出力機能は以下の通りです。
もちろん、何も読むかまたは書くのにそれらを使用できます--ファイル以外でも: メモリ、テープ、カード、レーザー光線は何でもコントローラに器具を取り付けます。
あなたが、これらのルーチンを何と呼ぶか重要ではありませんが、アーギュメントの並びと戻り型は、示されているようにいるに違いありません。また、異なった名前をそれらに与えると、あなたはkermit.hでプロトタイプを変えなければならないでしょう:

int
openfile(UCHAR * filename, int mode, struct k_date * k) (1.1)
openfile(struct k_date * k, UCHAR * filename, int mode) (1.2)
    Opens the named file in the given mode (1 = read, 2 = write, 3 = append).
Returns X_OK on success, X_ERROR on failure.
あたえられたモードによる指定されたファイルを開きます。

ULONG
fileinfo(UCHAR * filename, UCHAR * buf, int buflen, short * type, short mode) (1.1)
fileinfo(struct k_data * k,UCHAR * filename,UCHAR * buf,int buflen,short * type,short mode) (1.2)
    Gets information about the specified existing local file: size, date, and, if mode == 0, the file type (text or binary). buf and buflen apply to the file's date/time string.
Returns X_OK or X_ERROR.

指定された既存のローカルファイルの情報を得ます: サイズ、日付、およびモード=0　ファイルタイプ(テキストかバイナリ)を。bufとbuflenはファイルの日付/時間ストリングが当てはまります。

int
readfile(struct k_data *)
    Reads a buffer from the input file, and if the transfer is in text mode, converts the record format to standard Kermit Stream CRLF.
Returns X_OK or X_ERROR.
入力ファイルをバッファに読み込みます。
テキストモードの転送では、レコード形式を標準のカーミットStream CRLFへ変換します。

int
writefile(struct k_data *, CHAR * buffer, int length)
    Writes a buffer to the output file, and if the transfer is in text mode, also converts the standard Kermit Stream CRLF record format to whatever is required locally.
Returns X_OK or X_ERROR

テキストモードの転送では、バッファから出力ファイルを書くとき、標準のカーミットStream CRLFレコード形式を局所的に必要な物に変換します。

int
closefile(struct k_data *, UCHAR code, int mode)
    Closes the file. For output files, of course this flushes any pending buffers to the file before closing it; then it checks to see if the sending Kermit canceled the file transfer before it was finished (code == 'D'), in which case it discards the partial file instead of keeping it. The mode indicates whether it's an input or output file, so incompletely received files can be deleted if desired.
Returns X_OK or X_ERROR.
ファイルを閉じるとき。出力ファイルに関しては、それを閉じる前に、もちろん、これは、どんな未定のバッファもファイルにフラッシュします。
次に、終わる(コード='D')前に、送付カーミットがファイル転送を中止したかどうか確認するためにチェックします、その場合（中止）、それを保つことの代わりに部分的なファイルを捨てます。モードは、望まれているならそれが入力か出力ファイルであることにかかわらずそのように不完全に受け取られたファイルは削除できるのを示します。

DEBUGGING
If EK was built without NODEBUG defined, then if you include the -d option on the command line, the Unix-based sample version of EK creates a debug.log file in its current directory. In the production version, you would add -DNODEBUG to the C compiler CFLAGS to eliminate the debugging code. The sizes shown above include debugging. You can implement the debug function any way you want in your platform-specific i/o module.

EKが定義されたNODEBUGなしでビルドされたなら、あなたがコマンドラインにおける-dオプションを入れるなら、EKのUnixベースのサンプルバージョンはカレントディレクトリの中でdebug.log fileを作成します。
生産バージョンでは、あなたは、デバッグコードを排除するためにCコンパイラCFLAGSに-DNODEBUGを加えるでしょう。
上に示されていたサイズは、デバッグするのを含んでいます。あなたは、あなたのプラットホーム特有のいろいろな入出力モジュールで欲しいデバッグ機能を実装することができます