MNO - Latest News:- I began to suspect that the problem may have been an issue with my app not handling telnet command sequences (IAC DO/WILL/DONT/WONT XXXX etc.) and the server waiting for a response. However, I have just tested this with a code revision that handles the telnet commands coming from the server (in the minimal way comaptible with the telnet protocol spec). I still see the same problem on the PocketPC tcl version 8.4.3 :-(
It seems that whereas the same code on Linux (version 8.4b2,) and Windows 2000 (8.4.3) sees a batch of ~120 bytes from the server, the last three of which are a Telnet command (\xff\xfb\x01 corresponding to IAC WILL ECHO), the fileevent handler in the PocketPC version never sees this batch of bytes at all. It's as if it won't fire when data received from the socket contains the telnet command (maybe the \xff ?). (see Further news below - this does not seem to be the case after all)
It definitely seems to be the fileevent that's the problem since I can talk to the server fine as described at the bottom of the page with read and puts. I definitely see the telnet IAC WILL ECHO sequence in the server output that I fetch with read in that case too.
I've tried fconfiguring the translation and/or the encoding of the socket to binary but this makes no difference to the problem.
Further news - I have eliminated my hunch about the telnet \xff byte causing problems. I have used the server code from the telnet page on my linux box and tested the PocketPC against that. The problem still occurs. It seems to be that, put simply, on PocketPC, fileevent readable on a socket triggers once and only once. I can force my app. to work by using a kludge of using after to schedule polling calls to read but fileevent readable never again triggers :(
Original Discussion and Comments:-
MNO - Whilst knocking up a PocketPC application today PocketICS, I have noticed some weirdness with fileevent.
I can minimally demonstrate this with the following code snippet (adapted from the telnet page), which tries to connect to an internet chess server:-
#! /bin/sh
# THIS LINE MUST BE HERE \
exec tclsh "$0" ${1+"$@"}
package require Tk
proc telnet {{server localhost} {port 23}} {
global sock
set sock [socket $server $port]
fconfigure $sock -buffering none -blocking 0
fileevent $sock readable [list fromServer $sock]
global closed
vwait closed($sock)
unset closed($sock)
}
proc toServer {} {
global comm sock
puts $sock $comm
set comm ""
update
}
proc fromServer {sock} {
set data x
while {[string length $data]} {
set data [read $sock 4096]
if {[eof $sock]} {
disconnect $sock
return
}
if {[string length $data]} {
.t insert end $data
.t see end
}
}
}
proc disconnect {sock} {
global closed
close $sock
set closed($sock) 1
}
pack [text .t -font {Tahoma 7} -height 20 -width 40] [entry .e -textvariable comm]
bind .e <Return> toServer
telnet chessclub.com 5000Running this piece of code on either a Linux system (Tcl/Tk version 8.4b2) or Windows 2000 system (ActiveTcl 8.4.0) works exactly as expected - I get to the login prompt, can enter my handle in the entry box and this gets sent to the server which then prompts me for the password.
If, however, I run this on my PocketPC, (using the 8.4.3 tcl/tk on the Windows/CE page), I get the login prompt (i.e., proving that the fileevent has fired), and can send my handle, but I never see the password prompt in the text box (i.e., the fileevent doesn't seem to fire again).
The strange thing is that if I snoop the connection (my PocketPC internet connection is via my Linux machine) using tcpdump, I can see the handle being sent, and the response including the password prompt being sent back by the server. I can then even enter the password in the entry box, and see it go to the server and the login session continues fine. The fileevent never seems to fire again though, so all that I ever seem to get in my text box is the first set of output up to and including the login prompt.
Any ideas? Is this a bug in the Windows/CE Tcl/Tk version?
Could this be related to Tcl bug #719790 (fcopy -command hangs in Win NT4)? It looks like that bug only affects Tclkit, not tclsh - but somehow it sounds similar... -jcw
MNO - Could be. I have modified my code to keep count of cumulative bytes received just to see if the magic value of 4096 appears anywhere. I think not though - I'm pretty sure that there can't be more than about 500 bytes received before it stops triggering fileevent. (Actually, IIRC, I only ever see the first 119 bytes via fileevent).
escargo - Could you use sockspy to get another view of what is happening? (I don't know if it would be more useful than tcpdump.)
MNO - I don't think running sockspy on the linux node would help much since, as you note, I've got tcpdump running there. I wondered about running it on the PocketPC end but, of course, it is pure Tcl and relies on fileevent itself. I may try it there anyway tonight, in case it behaves differently, but if there is a bug then sockspy is probably going to be affected too... There looks to be one difference in the fconfigure behaviour of sockspy (it sets -translation binary which i don't). I don't know if this will make a difference or not. i did try the above code with -encoding binary set, but this didn't seem to change the behaviour any.
MNO - I have performed a test within tkcon on the PocketPC just using socket, fconfigure, read and puts (i.e. no fileevent) and this seems to work fine - I can conduct a session via the following type of exchange:
% set s [socket chessclub.com 5000] % fconfigure $s -buffering none -blocking 0 % read $s " . (server output) . login: " % puts $s myname % read $s " (more server output) password: " % puts $s mypassword % read $s " (more server output including welcom message and command prompt aics% " % puts $s icscommand % read $s "(output of icscommand)" % etc. etc.
Which does seem to point at the problem being in fileevent related bits of the channel handling code.
Another hunch... could it be related to the combo of sockets and encodings? -jcw
MNO Dunno - I did try the "mini-telnet" code at the top of the page also with a "-encoding binary" option on the fconfigure and it behaved the same.