#6 Empty messages in blocking mode

[Kristoffer Lawson]

I appear to be getting strange behaviour with channels
configured to be non-blocking combined with file events
and the [read] command. With this combination the
readable file event callback gets called twice for all
messages following the first.

The first message sent to the server written in tcludp
goes OK, but upon sending another message the callback
gets called with an empty message. Then it gets called
again with the actual message. The same pattern occurs
for all subsequent messages.

Interestingly enough, after reading the empty message
[eof $chan] returns 1, so the callback seemingly is
called because of a detected EOF.

I've attached a script (modified from what Pat posted
to IRC/Tcler's chat) that points to the problem.

The client I use for testing is netcat (nc), but I
believe I have seen the same behaviour with the actual
client too (not in my control).

[Kristoffer Lawson]

Test server showing the problem.

[Pat Thoyts]

Logged In: YES
user_id=202636

I continue to fail to reproduce this fault. I've tried tcl
8.2, 8.3 and 8.4 with udp1.0.4 and udp1.0.5 using netcat and
tcl as clients to this script. So far all on windows.

What OS are you using?

[Nobody/Anonymous]

Logged In: NO

Idem for me with little packets and a similar code and
configuration, but when receiving a big UDP packet (but only
ONE, thanks ethereal) from non-tcludp program, using tcludp
to get it, I need to use TWICE "gets $myudpchannel" to have
my packet complete: >4/5 of the packet firstly and then the
end (so the same with little packets as the first gets gives
an empty message).

Debian GNU/Linux 2.4.20
Active TCL/TK 8.4

Tested with tcludp 1.0.4 and 1.0.5

[Nobody/Anonymous]

Logged In: NO

(nobody bis)
It seems to be a string problem with the newline character,
when using udp as non-ascii data transfer.

[Pat Thoyts]

Logged In: YES
user_id=202636

In tcludp, we have a MAXIMUMBUFFERSIZE of 4096. If a packet
is larger than this, then it'll require more reads.

I can see no special handling of \n in the recieve code and
I suspect the culprit is somewhere in the Tcl channel subsystem.

[Pat Thoyts]

Logged In: YES
user_id=202636

I see this problem using Solaris 10.
proc Read {chan} {
set d [read $chan]
puts [list $chan [string length $d] $d]
}
set s [udp_open]
fconfigure $s -buffering none -blocking 0 -encoding binary
fileevent $s readable [list Read $s]
fconfigure $s -remote {ntp2a.mcc.ac.uk 37}
puts -nonewline $s abcd

Do the above a few times and you get
sock3 0 {}
sock3 4 xxxx

The same code on windows does not yield the empty read. If
we turn blocking on then the 0 read vanishes.

[Konstantin Khomoutov]

Logged In: YES
user_id=1350198
Originator: NO

I'm experiencing this on a Linux system (Debian Etch) and tcludp 1.0.8 running on stock Tcl 8.4.12. In Windows the same script works OK.

The script I use is identical to the Pat's regarding channel configuration.

By the way, ceptcl using the "receiver" facility works just OK in the same setup; here's the script:

package require ceptcl

set group 239.0.0.1
set port 4444

set sock [cep -receiver ProcessIncomingFrame -type datagram $port]
fconfigure $sock -translation binary -blocking 0 -buffering none \
-join $group -broadcast 1

proc ProcessIncomingFrame {sock addr port len msg} {
puts "$len from $addr:$port ([string length $msg])"
}

vwait forever