TCL(Tool Command Language) Scripting :: Can't figure out what's preventing the full message to send on the socket


	Can't figure out what's preventing the full message to send on the socket 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 <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' On May 23, 2:11 pm, Ralf Fassel <ralf@gmx.de> wrote: - Hide quoted text - > * 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 At 23 May 2007 13:59:07 -0700 Andrew Falanga <af300@gmail.com> wrote: - Hide quoted text - > 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. Things to check in the C++ code: Is the read() / recv() call being passed the proper arguments, etc.: is the buffer large enough, is the count being checked properly, and so on. What is slightly interesting is that it is getting four bytes. Four 8-bit bytes == 1 32-bit word. Are you doing something like: unsigned buffer[BUFFERSIZE]; /* should be unsigned CHAR buffer[BUFFERSIZE]; / read(socket,buffer,sizeof(buffer)); The above is seriously broken, but will compile without errors. Do a close eyeball check of the C++ code!!! > Thanks, > Andy -- Robert Heller -- 978-544-6933 Deepwoods Software -- Linux Installation and Administration http://www.deepsoft.com/ -- Web Hosting, with CGI and Database hel@deepsoft.com -- Contract Programming: C/C++, Tcl/Tk In article <1179953947.371807.291@r19g2000prf.googlegroups.com>, Andrew Falanga <af300@gmail.com> wrote: - Hide quoted text - >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. . . . Do I understand that correctly? Telnet sees everything you expect, but the C++-coded program is missing data? When I hear that, I take it as strong evidence that the mystery has been localized: something's not right in the latter program.