Timing with TcpClient

[Anton Shepelev]

Hello, all
(but how many `all' embraces?)!

The program I must modify contains code made of hacks and
crutches for sending text to a Zebra printer via TcpClient.
The original author informs me that he had to write it
without testing with an actual printer, whereas the emulator
he had, worked much smoother than the actual device, whence
the crutches, one of which I wanted to discuss with you:--

Without error handling, memory management, and other
irrelevant details, the printing algorithm is:

TcpClient cli;
NetworkStream str;
byte[] data;

cli = new TcpClient( host, port );
str = cli.GetStream();
data = Encoding.ASCII.GetBytes( text );

str.Write( data, 0, data.Length );
Thread.Sleep( Delay ); // ???

// Some paranoia:
str.Close (); cli.Close ();
str.Dispose(); cli.Dispose();

The Sleep() call, marked with ??? above, is necessary for
the last page to be printed in a timely manner. Wihout this
delay, the device prints the last page not when the data is
sent over network, but when the next batch comes in, even an
hour later! How is it possible, and what can be the effect
of a delay before closing the stream?

The overload NetworkStream.Close(Int32) is documented as
"waiting the specified time to allow data to be sent" before
closing. What may be the reason such an overload if TCP
itself guarantees reliable data delivery without the need of
arbitrary waits? Do you know networking sufficiently well
to tell whether setting TcpClient.NoDelay is worth trying,
or using NetworkStream.SendBufferSize exactly equal to the
number of bytes in the packet?

P.S.: Considering the traffic and S/N ratio in this group,
would a moderated mailing list make sense?

[Arne Vajhøj]

Post by Anton Shepelev
Hello, all
(but how many `all' embraces?)!

Probably not many.

Post by Anton Shepelev
Without error handling, memory management, and other
TcpClient cli;
NetworkStream str;
byte[] data;
cli = new TcpClient( host, port );
str = cli.GetStream();
data = Encoding.ASCII.GetBytes( text );
str.Write( data, 0, data.Length );
Thread.Sleep( Delay ); // ???
str.Close (); cli.Close ();
str.Dispose(); cli.Dispose();
The Sleep() call, marked with ??? above, is necessary for
the last page to be printed in a timely manner. Wihout this
delay, the device prints the last page not when the data is
sent over network, but when the next batch comes in, even an
hour later! How is it possible, and what can be the effect
of a delay before closing the stream?

This all seems rather weird.

Based on the description I would try to send the data
with an extra FormFeed added at the end and close
immediately and see if that works.

Arne

[Anton Shepelev]

Based on the description I would try to send the data with
an extra FormFeed added at the end and close immediately
and see if that works.

No, it didn't, but a delay before closing the connection
plus the .NoDelay flag on it helped. I think it a bug in
the printer firmware, offering a defective implementation
of the server...