[...]
http://www.cs.columbia.edu/~xiaotaow/research/tcludp/ [no broadcast capability?]
Yes, it has the capability to transmit, via puts.
Also http://students.cs.tamu.edu/mmiller/tcl/channel.html .
30Jan2003 Mike Tuxford It was mentioned in c.l.t that there aren't many examples of tcludp usage around so I'll add this simple one that listens on port 1434 which is the MSSQL port and has been in the news a lot lately due to major exploits.
proc udpEventHandler {} {
global fd
puts "event triggered..."
puts "Data: [gets $fd(udp)]"
puts "Peer: [udp_conf $fd(udp) -peer]"
return
}
set fd(udp) [udp_open 1434]
fileevent $fd(udp) readable udpEventHandler
puts "Listening on udp port: [udp_conf $fd(udp) -myport]"
vwait __forever__
[PT] writes: First - thank you for giving an example - I find that I need to stop buffering as well using 'fconfigure $fd(udp) -buffering none'
The above example looks to be using tcludp. I have some trouble with this package. It isn't stubsified, it doesn't present itself as a package and it fails to work for binary data (at least on windows). Try sending a packet like
set s [udp_open] fconfigure $s -buffering none -translation binary udp_conf $s localhost 1434 puts -nonewline "Hello, World" puts -nonewline $s "\x00\x01\x02\x03\x04"
The first ASCII packet is OK but the second stops at the first null and the remainder of the received packet is made up of leftovers from the receiving buffer.
Looking at the package code - it is using the older style argv passing Tcl command API. Fixing it up to use Tcl_Obj might help with binary handling.
Is anyone actively maintaining this package? Does it work better under unix? And what license is the code under. I'm somewhat tempted to fix it so I can use it with the tcllib dns package - but I need to clarify the license.
03Jan2003 Mike Tuxford Well, I haven't done any trasmitting of data as my interest has been in a port watcher I've been working on that listens on common exploit ports. But, offhand I see no flushing after your puts's.
The -buffering none deals with the flushing. If I sent the above though we get this on the server:
Data: "Hello, World!" 13 Peer: 127.0.0.1 1194 event triggered... Data: "Xello" 5
where X substitutes for a NUL char. As you can see I have received the correct number of characters but someone is using strcpy when they should use memcpy :)
MT: Sorry about the flush. Yeah, I don't know. I was just playing with it myself and get the same weirdness. Also, if I don't use a dummy proc + vwait at the end I get an 'Illegal instruction' which baffles me. An 'after 2000' made no difference.
event triggered... Data: Hello, World Peer: 127.0.0.1 2754 event triggered... Data: `abc Peer: 127.0.0.1 2754