JPH0443743A - ネットワークのプリンタ出力方式 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 〔産業上の利用分野〕 本発明は、ネットワークを介してワークステーションと
サーバとを結合する場合、ネットワークのデータ圧縮・
伸長機能を効率化してサーバのプリンタに出力する方式
に関する。

［従来の技術］ 従来より、パーソナルコンピュータを用いて種々の処理
を行う複数のワークステーションと、台のす〜バ（資源
供給センタ）とをネットワークを介して接続し、相互に
情報交換を行っためのパソコン通信が行われている。

ある１つのワークステーションからサーバのリモートプ
リンタにイメージデータを出力する場合、データをその
ままの状態でネットワークを通して送信した場合には、
イメージデータ全てを送信し終るのには時間がかかり過
ぎる。情報をディジタルに変換して送信すると、時間は
格段に減少されるとともに、メモリ容量も低減できる。

なお、ネットワークによる画像通信については１例えば
、グファクシミリと新画像通信１１９８：’年３月１０
日産報畠版（株）発行、ｐｐ、１０１〜１３０に記載さ
れている。

［発明が解決しようとする課題］ パソコン・ネットワークにおいて、イメージデータをリ
モート・プリンタに出力する場合、ブタ量が多過ぎるた
め、全てのデータを送信し終るまでには時間がかかり過
ぎるという問題があった。

この送信中の期間は、ワークステーション側は、何も他
の仕事ができなくなってしまうため、この時間を短くす
ることが要求されていた。

本発明の目的は、このような従来の課題を解決し、イメ
ージデータをリモート・プリンタに出力するための時間
を短縮でき、データ転送速度を格段に早くすることがで
きるネットワークのプリンタ出力方式を提供することに
ある。

［課題を解決するための手段］ 上記目的を達成するため、本発明によるネットワークの
プリンタ出力方式は、ワークステーション側から圧縮フ
ラグＯＮをヱ・ットワークに要求する二とによｌハネッ
トワークでは先頭に圧１縮フラグのパケットを送出した
後、ワークステージヨシから送られたデータを１パケツ
ト分毎に圧縮して、複数パケット分を１パケツト送信期
間にサーバ側に送信し、サーバ側では、先頭のフラグパ
ケ・ソトにより圧縮パケットであることを判断して、受
信したデータを伸長し、プリンタに出力することに特徴
がある。

［作　　用〕 本発明においては、通常のデータが１パケツト分を例え
ば１５１８バイトで送信するところを、ネットワークで
この１５１８バイトを圧縮して５００バイト程度に短縮
し、この処理を３回行うことにより、３パケツト分を１
パケツト送信期間に送出できるようにする。１パケツト
が圧縮されていることを示すために、先頭に圧縮フラグ
パケットを送出した後、データパケットを送出する。

これにより、データ転送速度を従来の３〜４倍にアップ
させる。その結果、ワークステーションからサーバのリ
モート・プリンタにイメーシデタを転送して、プリント
出力する場合にも、高速に出力することが可能である。

［実施例］ 以下、本発明の実施例を、図面により詳細に説明する。

第１図は、本発明における送り側（つまり、ワタステー
ション側）の処理手順を示すシーケンスチャートである
。

アプリケーション側では、リモート・プリンタにデータ
を出力する際に、動作に先立って、データの圧縮を行う
か否かをネットワークに通知する（ステップ１０１）。

ネットワークでは、この圧縮フラグがＯＮの場合には、
それ以降のデータを圧縮して、圧縮データが１パケツト
分になったならば、これをサーバに送出する。

通常、データは】パケット（例又は、〕５〕８バイト）
毎に送出されるが、この１パケツトのブタを圧縮して５
００ハイドにした場合には、残りの１０１８バイト分の
データを１パケツトとして送信することが可能となる。

その結果、従来のパケット通信では、３〜４パケツトで
送出していたデータを、本発明では、１パケツトで送出
することが可能となる。

データの送受信は、ｌパケット毎にネットワークで衝突
検出が行われるので、１回の送信で１パケツト分（１５
１８バイト）の全てを使用した方が効率がよくなる。従
って、データ転送速度は、従来の３−４倍に向上する。

ネットワークは、圧縮フラグがＯＮの場合、ブタを送出
する前に、フラグＯＮを示すパケットをサーバに送出し
て（ステップ＋０２）、スプール・ファイルの先頭に圧
縮フラグパケットが到着するようにする。

ワークステーション側では、データを送出し終ったなら
ば（ステップ１０３）、このフラグをＯＦＦにする必要
がある。もし、ユーザがこのフラグを変更しない場合に
は、以後、このフラグ情報は保持されるものとする。

ネットワークでは、それ以降のデータを、】パケット９
毎に圧縮してかうサーバに送出する（ステップ１０４）
。

第２図は、本発明におけるサーバ側の処理手順を示すシ
ーケンスチャートである。

サーバ側では、ワークステーションから送信されてきた
データをそのままスプールし、スプール完了後にプリン
タ・ドライバに送出する（ステップ２０１）。

プリンタ・ドライバ内において、データ圧縮の有無を判
断し、先頭にフラグパケットがある場合には、圧縮パケ
ットであると判断する（ステップ２ｏ２）。圧縮フラグ
がＯＮの場合には、それ以降のデータを伸長してから（
ステップ２０３）、プリンタに出力する（ステップ２ｏ
４）。

１つのスプールファイルが出力し終ったならば、状態は
デフォルトに戻り、また次の圧縮フラグパケットを受は
取るまで、通常の出力を行う。

第３図は、本発明の送信側と受信側の処理データの説明
図である。

第３図（ａ）はワークステーションのパケット処理を示
し、第３図（ｂ）（ｃ）はネットワークにおける圧縮処
理と送信処理を示し、第３図（ｄ）はサーバおよびプリ
ンタ・ドライバ側の受信・伸長処理を示している。

ワークステーション側では、データ送出に先立って、圧
縮フラグＯＮの要求をネットワークに送り、ネットワー
クから応答が到着したならば、１５１８バイト毎にデー
タをネットワークに送出する（第３図（ａ）参照）。

ネットワークでは、］５１８バイトを５００バイトに圧
縮して、３パケット分をそれぞれＡ、Ｂ。

Ｃに圧縮しく第３図（ｂ）＃照）、先頭に圧縮フラグＱ
ｌ’Ｊのパケットを送出した後、従来の１パケット送出
期間にこれらＡ、Ｂ、Ｃの３パケット分を送出する（第
３図（Ｃ）参照）。

サーバ側では、スプール完了後にデータをプリンタ・ド
ライバに送出することにより、ドライバでは、先頭にフ
ラグパケットがあることで圧縮パケットであることを判
断し、Ａ、Ｂ、Ｃをそれぞれ１５】８バイトのデータに
伸長処理する（第３図（ｄ）参照）。

このように、ワークステーショ〉側でデータの圧縮を行
い、サーバ側でこれを伸長することにより、ネットワー
クを通るデータ量が格段に少なくなるため、データの送
受信にかかる処理時間が短縮される。その結果、ワーク
ステーション側では、プリンタへのデータ出力の後、早
く他の作業に移ることができるので、作業効率は向上す
る。

〔発明の効果〕

以上説明したように、本発明によれば、１パケツト毎に
圧縮してネットワークに送出するので、データ転送速度
は従来の３〜４倍も高速となり、ワークステーション側
の処理時間が短縮される。

【図面の簡単な説明】

第１図は本発明の一実施例を示すワークステジョン側の
処理シーケンスチャート、第２図は本発明の一実施例を
示すサーバ側の処理シーケンスチャート、第３図は本発
明におけるｌパケットの圧縮状態を示す説明図である。 １０１．１０３：ワークステーションの処理、１０２．
１０４：ネットワークの処理、２０１゜サーバの処理、
２０２，２０３，２０４・プリンタ・ドライバの処理。 第 図 ワークステーション側 ネットワーク

Claims (1)

【特許請求の範囲】
1. （１）ネットワークを介してワークステーションからサ
   ーバのリモート・プリンタにイメージデータを出力する
   ネットワーク送受信システムにおいて、ワークステーシ
   ョン側から圧縮フラグＯＮをネットワークに要求するこ
   とにより、ネットワークでは先頭に圧縮フラグのパケッ
   トを送出した後、上記ワークステーションから送られた
   データを１パケット分毎に圧縮して、複数パケット分を
   １パケット送信期間にサーバ側に送信し、該サーバ側で
   は、先頭のフラグパケットにより圧縮パケットであるこ
   とを判断して、受信したデータを伸長し、プリンタに出
   力することを特徴とするネットワークのプリンタ出力方
   式。