Note that
flush is effective only when it comes to
sending data down a channel, not reading from it. Just like the C
fflush() system call, it causes any characters currently buffered to be sent. If you use Tcl's
fconfigure command to set the channel to
-buffering none, then data is not buffered at all; each
puts call on the channel immediately sends the data.
In terms of reading data from a channel, since
ramsunder said that the data isn't line-oriented, I'm assuming that it's binary. So first of all, you should remember to use the
fconfigure command to set the channel to
-translation binary. This prevents Tcl from trying to interpret end-of-line sequences (and thus mangling binary data). It also implictly sets the encoding to binary as well, so Tcl doesn't try to do any character encoding translations.
Then to actually read the data, you'll use
read, rather than
gets. The default behavior of
read, if you don't specify the number of characters to read, is to read all data from the channel until it encounters an EOF notification -- blocking until it's read all the data. This might be appropriate in your case, particularly if the amount of data transmitted is small and you don't need extended interaction on the channel. If that's not the case, then you'll want to specify the number of characters to read from the channel. For example:
Code:
set sock [socket $host $port]
fconfigure $sock -translation binary
set data [read $sock 32]
Note that this is still a
blocking read; it there isn't at least 32 bytes of data available,
read blocks until there is. If you don't want that behavior, you'll have to configure the channel to be
non-blocking:
Code:
fconfigure $sock -blocking 0
In non-blocking mode,
read might not read as many characters as requested: once all available input has been read, the command returns the data that is available rather than blocking for more input. You'll now need to test the number of characters actually read (using
string length), and potentially buffer incomplete messages. The other issue of using a non-blocking channel is that you'll need to use the
eof command after each
read (or
gets) to determine whether or not you've received an EOF on the channel.
- Ken Jones, President, ken@avia-training.com
Avia Training and Consulting,
866-TCL-HELP (866-825-4357) US Toll free
415-643-8692 Voice
415-643-8697 Fax