WindowsXPクライアントから、プリンタサーバを接続したプリンタに印刷すると、
　１ページの途中とか、２ページ目の最初で止まる。
　しばらくすると、また１ページ目から印刷が始まる。
　もっと多いページ数のときは、数ページで印刷エラーになってしまう
という相談がありました。

　当初はプリンタかプリントサーバの故障だろうということで、同じ型番の予備機と交換したのですが、おなじ症状。
だったら、通信障害だろうということで、ハブやLANケーブルを交換したが改善されず。
　プリントサーバを使用せずにUSBケーブルでPCに直接接続すると正常なので、やはりLAN関係の問題だと判断しました。
　で、しかたないので、リピータハブ、プリントサーバ（とプリンタ）、PCをそれぞれ１台ずつ接続し、さらにWiresharkをインストールしたPCをハブにつないで、印刷データをキャプチャしました。
　それをみると、「標準TCP/IPポート」で接続したプリントサーバにはRAWプロトコルでデータを送信しているということがわかりました。
　あー、「ポートの構成」でLPRを選択しなかったらRAWだったんだということを思い出しました。

　RAWプロトコルのままでも、LPR用のプリントサーバは印刷できるからこれまでは特に気に留めなかったのですが、LPRとRAWの決定的な違いを気にしていなかった私が悪うございました。

　RAWプロトコルではSNMPを使ってプリンタやプリントサーバの情報を収集します（例えばキュー名とか）。
　さらにLPRでは、、正確なバイト数が制御ファイルに含まれている必要があることです。

「標準 TCP/IP ポート」モニタは、印刷データのバイト数を把握しておらず、 非常に大きなバイト数をプリントサーバ に送信して印刷を開始し、 ジョブの完了後は、接続を閉じるだけだそうです。

　http://technet.microsoft.com/ja-jp/library/cc728317%28WS.10%29.aspx

　この違いが、パソコン側が印刷データをプリントサーバに送信し、プリントサーバの受信バッファがあふれたとき、「どれだけの情報を再送信するか」の違いとなって現れるようです。
　プリントサーバからTCP Zerowindowが帰ってきたあとでも、パソコン側とはTCP Ackでどのシーケンス番号から再送信させるかで制御していて（TCPの当然の挙動）、ちゃんと印刷できました。
　これがRAWだとパソコン側は再送信を繰り返して、一定時間Ackがなかったら失敗したとみなしているような動作です。

　LPR用のプリントサーバでは、きちんとLPRを指定して、バイト数カウントさせないとこういうトラブルになるんだという、貴重な体験をしました。
　１０年ほど前だったら、もっと慎重に設定したんですが、いまはとりあえず動いてしまうので油断してました。