Posts: 3,415
Threads: 158
Joined: Jan 2006
01-01-2009, 08:47 AM
(This post was last modified: 01-01-2009, 09:15 AM by wuench.)
Getting this in the SNMP driver. Tokens are not being filled in...
Unhandled Exception (MEng.System.Runtime.DGramSocket #16) - The max buffer size (%(1)) is smaller than the bytes requested (%(2))
BTW, I get this when I do a
c4Count := m_Sock.ReadFrom(ipSrc, 0, m_bufResp, Card4.kMaxValue);
Is that the expected behaviour? Shouldn't kMaxValue be LARGER than any possible buffer size?
Posts: 1,763
Threads: 76
Joined: Jun 2007
What are you using for the constructor for the buffer? The docs only list 1 constructor that requires a starting and maximum size, but you can use a default constructor with just MemBuf m_bufResp;. Maybe this is using some type of default maximum size that is less than kCard4.MaxValue.
It's the early bird that catches the worm, but it's the second mouse that gets the cheese...
Posts: 1,763
Threads: 76
Joined: Jun 2007
Looking at the 2nd paragraph for the ReadFrom() method tells the story I believe...So it will only expand the buffer to its maximum size that was set when it was initialized. The only way the buffer would get to Card4.kMaxValue would be if that was what the buffer was initialized at.
Quote:If the passed memory buffer's maximum size is not sufficient to hold the packet, a SocketErrors.DGramBufToSmall exception will be thrown. Be careful though, because this method will allocate the buffer up to the ToRead size, so don't set the buffer max to some ridiculous value and set ToRead to that value, because it will allocate the buffer up to that size. Datagram packets are limited in size anyway, so set it to some reasonable size, such as 32K and that should hold any legal datagram packet.
It's the early bird that catches the worm, but it's the second mouse that gets the cheese...
Posts: 3,415
Threads: 158
Joined: Jan 2006
Ok, that explains it. I wasn't thinking about the buffer itself, that max is probably much smaller. I was just trying to flush the socket buffer since reloading the driver wasn't doing it. There is no method on the DGram socket to close it. I found another way by checking if data is available first.
Thanks.
The tokens still need to be fixed in the exception though...
Posts: 40,483
Threads: 491
Joined: Aug 2002
01-01-2009, 11:53 AM
(This post was last modified: 01-01-2009, 11:59 AM by Dean Roddey.)
I'll take care of the error message tokens. And also the outgoing datagram sender was comparing the bytes to send to the max buffer size instead of the current buffer allocation which was wrong also. The incoming should compare against the max and the outgoing should compare against the current. So I fixed that also. It's the little things in life...
Dean Roddey
Explorans limites defectum
Posts: 1,763
Threads: 76
Joined: Jun 2007
What I find interesting with things like this is it really shows the power and complexity of the product. Even though the product itself is fairly mature basic things like the buffer comparison still crop up because a vast majority of the code base is under-utilized. Just goes to show if you have enough monkeys pounding on keyboards it will eventually flush out most things.
It's the early bird that catches the worm, but it's the second mouse that gets the cheese...
Posts: 40,483
Threads: 491
Joined: Aug 2002
I'm always amazed at how long bugs can exist without being ever noticed. Some of them it seems would be impossible to go unnoticed by they'll be there for many years before something happens that brings them to light. Iit's heading towards 800K lines of code, so I guess that's not to be unexpected. But with so much code, you'd think that basically almost all the methods of the underlying fundamental stuff (like sockets) would be used fairly commonly.
But there's a lot of stuff down there, and of course people try not to write code with errors and to do the right thing, so sometimes it's only when the docs are insufficient or misunderstood or under-read that people will do something wrong that brings out something like this.
Dean Roddey
Explorans limites defectum
Posts: 1,763
Threads: 76
Joined: Jun 2007
Do you have an official release number for the underlying CIDLib Framework? Last open source release was 1.1.0 and that has been 9 years.
It's the early bird that catches the worm, but it's the second mouse that gets the cheese...
Posts: 3,415
Threads: 158
Joined: Jan 2006
I think no one is using DGramSockets. SNMP is UDP based, and UDP is pretty rare these days.
But if anything is going to pull out some bugs it's this friggin SNMP driver. I don't know how many lines of code it has, but it's one complex beast. I was going to add some simple enhancements today and I am already many hours in...
Posts: 40,483
Threads: 491
Joined: Aug 2002
I just keep the CQC and CIDLib code base versions the same, for simplicity's sake. So it's at whatever release the CQC stuff is.
The Omni driver has been UDP based for a long time, but of course I know now it all works so I never did anything that would have raised the issue above.
Dean Roddey
Explorans limites defectum
