Re: tcludp - bug when closing 1-of-2 listening ports

Vera schrieb:
Alexandre Ferrieux schrieb:
On Nov 3, 2:07 am, Alexandre Ferrieux <alexandre.ferri...@xxxxxxxxx>
wrote:
If I were to guess, I'd say something like a zero-length UDP packet...
but who knows ?

Update 2: I think I have a better characterization of the behavior
now.
It is indeed linked with zero-sized UDP packets.
I have found a deterministic way of producing them (as witnessed by
Wireshark when sending over the LAN):

% set s [udp_open]
% fconfigure $s -remote {somemachine 3000} -buffering none
% puts -nonewline $s titi
% puts -nonewline $s titi
% puts -nonewline $s titi
% close $s

This sends 3 normal UDP packets + 1 zero-sized.
Notice that all this is at interactive speed (no race condition), and
that three 'titi' are needed (two are not enough). Now combined with
your receiver, sending an "exit" packet then a zero-sized one, this
locks the receiving code, somewhere inside the intricate tcludp
machinery,

Several observations:
(1) The speed of the sending sequence has no effect (contrarily to my
first impression)
(2) The zero-sized packet wreaks havoc in tcludp only if it comes on
a closed socket (your case)
(3) Tcludp is not supposed to send zero-sized UDP packets
(4) However it should handle them gracefully, because some other
source can send them.

So I think we have at least two bugs, one on the write side (producing
zero-sized packets) and one on the read side (locking an internal
thread when these beasts come at the wrong time).

I think you should forward this to the maintainer.

-Alex


Congratulation Alex, great work.
Can you, please, send me the method, NOT to get the bug?
Your handcrafted sender, you used at first?

Since you can reproduce the bug, I must not longer search for an PC not updated to XP SP3.


Alex,
I can reproduce the behavior, 2 packets will work, 3 not.
Here is the working output:
----------------------------------------------------------------
C:\user\vera\Projekte\tcludp\test>tclsh85 udpDoubleReceiver.tcl
package udp has version: 1.0.9
Listening on udp port: 1300
Listening on udp port: 1310
AWAIT_EXIT = 2
recv at 1300: 4 {titi}
recv at 1300: 4 {exit}
udp socket at port 1300 closed
AWAIT_EXIT = 1
recv at 1310: 3 {bla}
recv at 1310: 4 {exit}
udp socket at port 1310 closed
AWAIT_EXIT = 0
C:\user\vera\Projekte\tcludp\test>
----------------------------------------------------------------

and here the not working:
----------------------------------------------------------------
C:\user\vera\Projekte\tcludp\test>tclsh85 udpDoubleReceiver.tcl
package udp has version: 1.0.9
Listening on udp port: 1300
Listening on udp port: 1310
AWAIT_EXIT = 2
recv at 1300: 4 {titi}
recv at 1300: 4 {tata}
recv at 1300: 4 {exit}
udp socket at port 1300 closed
AWAIT_EXIT = 1
^CBatchvorgang abbrechen (J/N)? j
----------------------------------------------------------------

May be this helps me finding the bug.

--
Vera
.

Relevant Pages

  • Re: UPD better than TCP in streaming video/audio ?
    ... > UDP gains speed over TCP because it carries no information that would ... it doesn't even know that packets were lost. ... which is perfect for UDP. ... > Finally, there's the possibility of multicast data - for instance, a live ...
    (microsoft.public.win32.programmer.networks)
  • Re: Linux equivalent for ioctlsocket(FIONREAD) on datagram sockets
    ... Imagine that fast CPU sends a burst of UDP ... spirit of UDP standard should do in that particular case? ... blocking a clling thread until the NIC hardware ... reads one or more packets from socket's send buffer freeing up space ...
    (comp.os.linux.development.apps)
  • Re: NTP and Firewall help needed.
    ... >>port 123 for udp and tcp. ... The action here is applied for packets that fall off ... > - ACCEPT any and all traffic coming from the localhost interface ...
    (comp.os.linux.setup)
  • Re: Possible bug in .Net 2.0 udp sockets?
    ... You won't miss any UDP packets with a buffer that large! ... R> I called BeginReceiveFrom() several times on purpose, ... If you don't do that, indeed, UDP stack can drop packets. ... it stores it in the queue. ...
    (microsoft.public.dotnet.framework)
  • Re: Update: UDP 770 Potential Worm
    ... > the network immediately after the 'attack', ... were no packets indicating some form of replication. ... I noticed that the UDP ... > of the UDP datagrams is the IP address of the proxy? ...
    (Incidents)