--===============1314653482==
Content-Type: multipart/alternative;
boundary="----=_Part_45961_11429054.1164633951949"

------=_Part_45961_11429054.1164633951949
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,
a don't know, that I found a bug, or it's a feature
I use one C++ application, that polls our network equipments every 10
minutes. It sends about 2000 get requests every time.
It has been worked for 2 years on linux 2.4 kernel machine, and i had to
migrate it last week to one new server, with v2.6 kernel. In the new machine
it ran 3-6 times, and after that it hang in recvfrom() libc function, that
called from snmpUDPDomain.c's setsnmp_udp_recv() function. Maybe because the
UDP answer packet lost in the network, and did not arrive. I'm not an
advanced programmer, but I saw in the man of recvfrom(), that if the
socket's O_NONBLOCK option is not set it would hang, and is waiting for the
answer.
I saw in the TCP sockets has this option, so I modified the UDP initiator
setsnmp_udp_trasport() function to set O_NONBLOCK like in the TCP code, and
after that my program works correctly.
Both machine's OS is Debian Sarge, only the kernels are different ones.

Is that a good workaround, or is that a bug?

Qrta

------=_Part_45961_11429054.1164633951949
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,
a don't know, that I found a bug, or it's a feature
I use one C++ application, that polls our network equipments every 10 minutes. It sends about 2000 get requests every time.
It has been worked for 2 years on linux
2.4 kernel machine, and i had to migrate it last week to one new server, with v2.6 kernel. In the new machine it ran 3-6 times, and after that it hang in recvfrom() libc function, that called from snmpUDPDomain.c's setsnmp_udp_recv() function. Maybe because the UDP answer packet lost in the network, and did not arrive. I'm not an advanced programmer, but I saw in the man of recvfrom(), that if the socket's O_NONBLOCK option is not set it would hang, and is waiting for the answer.

I saw in the TCP sockets has this option, so I modified the UDP initiator setsnmp_udp_trasport() function to set O_NONBLOCK like in the TCP code, and after that my program works correctly.
Both machine's OS is Debian Sarge, only the kernels are different ones.


Is that a good workaround, or is that a bug?

Qrta



------=_Part_45961_11429054.1164633951949--


--===============1314653482==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?p...rge&CID=DEVDEV
--===============1314653482==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/...et-snmp-coders

--===============1314653482==--