Google Code Search finds "about 50" instances of it in the stuff it indexes. Might even could track down Patient Zero through that if you're really bothered by it. :)
| [reply] |
I need to look around my desk at home to try to determine
where I got the extra "new" from. I have been using Lincoln
Stein's Perl networking book (examples probably correct),
the Perl Cookbook and many Google examples. My guess is that
I got it from a Google example.
Inside the if blocks I changed the "new" lines to look like:
$MySocket = IO::Socket::INET->new(Proto => 'udp',
After correcting the "new" issue I APPEAR to fail to
operate in what seems to be the exact same way. From the
command line the send statements whip by quickly. The recv
statements pause for the length of alarm time and repeat
for several retries. This is exactly what I currently
expect to see on the command line. But, I am not seeing
any activity on the hub (quad card only) LEDs.
Looking at this in a little more detail I used Ethereal
(now WireShark) on the machine that has the quad port cards.
ARGUMENT A
Packets from 192.168.22.30 to 192.168.21.28
No packets were seen on eth10 (the sending end)
ARGUMENT B
Packets from 192.168.21.28 to 192.168.22.30
No packets were seen on eth8 (then sending end)
ARGUMENT C
Packets from 192.168.21.28 to 192.168.20.223 (NOT quad card)
No packets were seen on eth8 (I hoped this was the sending end)
4 UDP packets were captured on eth0 (part of the .20 net)
THUS:
1) I think I can send from box to box with the "my" and
"new" fixes. Thank you for the good suggestions. With this
I should be able to work on my required final goal.
2) I do not seem to be able to get out of the box when I
try to go from one port to another port on quad cards in the
same box. I was told to expect this. Is there a way around
this? Can I use a different net for each port of the quad
cards to prevent "route" from taking the unnecessary
segments out of the transmission? This would be helpful for
single machine code development and other test projects
down the road.
3) My "argument C" example shows "route" changing my ports
for me. The packet went out the port that makes good sense,
not the port I coded. At times it would be handy if I could
overpower this "feature" of good routing.
Thank you for the help. I can proceed now. If there are
any suggestions on how I can force my routes (items 2 & 3)
I would appreciate additional information.
Thanks,
Bruce
| [reply] |