Tcl - Can't figure out what's preventing the full message to send on the socket

Author

Can't figure out what's preventing the full message to send on the socket

Andrew Falanga

2007-05-23, 7:12 pm

Hi,

Please look over the below driver script and tell me where I'm going
wrong. I'm writing a script to control a program on another computer
that will use TCP to communicate back and forth. The other program
will send data to this script to be logged and also to send a state
file. You'll see the two handlers in the code. What is below is only
a skeleton script designed to help me figure this out on a smaller
scale that the full fledged control script.

What needs to happen, is that the remote program needs to send data
strings to log in this. That is working just fine. My problem, at
this point, is the exchange to prepare for a state file transfer from
the remote program to the script. The remote program opens another
socket on the server socket in TCL, and then sends a string
identifying that it wants to send up a state file. The script is
supposed to respond with "STF-READY," but all that is sent is "STF-".
For whatever reason, I cannot determine what is preventing the "READY"
part of the string from being sent. I've worked at it long enough,
it's now time to ask for some extra eyes.

The remote program is C++ and is therefore off topic here, but FYI the
program uses select to wait for readable data on the socket. I get
"STF-", realize it's not all I'm looking for, reset my file descriptor
sets for select and recall select on my socket to wait for the rest.
I then timeout, and the "READY" part of the string is never received.

Thanks for any help,
Andy

set done 0

set logFile [open testrun.log w]

proc LogOutput { sd } {
global logFile done
if { [eof $sd] || [catch { gets $sd str }] } {
close $sd
set done 1
return
}

puts $str
puts $logFile $str
}

proc ReadStateFile { sd } {
set fd [open state_info w]

fconfigure $fd -translation binary -buffering none

while { ![eof $sd] } {
puts -nonewline $fd [read $sd]
}

close $sd
flush $fd
close $fd
}

proc Accept { sock addr port } {
puts "new connection from $addr on port $port"

puts "current socket config:"
puts [fconfigure $sock]

fconfigure $sock -blocking 0 -translation binary -buffering line

puts "now socket config:"
puts [fconfigure $sock]

gets $sock s

puts "gets has completed, setting event handler"
puts "read: $s"

if { [regexp {LOG-START} $s] } {
puts "configuring logging"
fileevent $sock readable [list LogOutput $sock]
} else {
puts "configuring for state file receipt"
#fconfigure $sock -blocking 0 -translation binary -buffering
line
puts $sock "STF-READY"
fileevent $sock readable [list ReadStateFile $sock]
}
}

set servSock [socket -server Accept 9923]

puts "entering the event loop, waiting for a connection"
vwait done

Andrew Falanga

2007-05-23, 7:12 pm

On May 23, 2:11 pm, Ralf Fassel <ralf...@gmx.de> wrote:
> * Andrew Falanga <af300...@gmail.com>
> | The remote program is C++ and is therefore off topic here, but FYI the
> | program uses select to wait for readable data on the socket. I get
> | "STF-", realize it's not all I'm looking for, reset my file descriptor
> | sets for select and recall select on my socket to wait for the rest.
> | I then timeout, and the "READY" part of the string is never
> | received.
>
> - You could try to 'flush' after the puts, though it should not make a
> difference.
> - You could try to use a TCL-test program at the remote side to see
> whether it also receives only "STF-". If the remote TCL program
> sees the whole string, you would know where to look :-)
>
> My EUR 0.02...
> R'

I had tried using flush earlier, but as you noted it made no
difference. It was something of a desperation move because the
channel is configured to be non-buffered.

I did do a variation on your second suggestion. I start the script I
posted here and telnet in, posing as the thread that would start the
state file transfer. I'm getting a full string "STF-READ".
Therefore, it is a genuine curiosity as to why I'm only getting a
partial string on the remote side.

Thanks,
Andy

Sponsored Links