Exception : System.Net.Sockets.SocketException

[lextudio-support]

Hello,

I'm using SharpSNMP version 9.0.1 and I have the following exception throw by the library.
Exception : System.Net.Sockets.SocketException :: A message sent on a datagram socket was larger than the internal message buffer or some other network limit, or the buffer used to receive a datagram into was smaller than the datagram itself

After some investigation, it appears that in my project, we receive large SNMP pdu, more than 8kb.
In the interface we can only manage the max pdu size but by default it's near 64kb (Messenger.MaxMessageSize 65507 bytes).
But at Socket level the value take into account is the defaut value from Socket.ReceiveBufferSize: Definition is as follow:
//
// Summary:
// Gets or sets a value that specifies the size of the receive buffer of the
// System.Net.Sockets.Socket.
//
// Returns:
// An System.Int32 that contains the size, in bytes, of the receive buffer.
// The default is 8192.
//
// Exceptions:
// System.Net.Sockets.SocketException:
// An error occurred when attempting to access the socket.
//
// System.ObjectDisposedException:
// The System.Net.Sockets.Socket has been closed.
//
// System.ArgumentOutOfRangeException:
// The value specified for a set operation is less than 0.

After managing to buil my own version of the library using Messenger.MaxMessageSize for the socket buffer allocation, the problem is fixed.

Regards,
Rémi

Original Reported Date: 2016-06-22T04:43:20.513-07:00
Planned For Release:
Original CodePlex ID: 7291

[lextudio-support]

Copied from CodePlex without authors:

Thanks for the report. Will analyze and get back later.

Original Posted Date: 2016-06-25T05:34:30.9-07:00

[lextudio-support]

Copied from CodePlex without authors:

Further analysis shows that if we force the ListenerBinding class to use a small buffer (_bufferSize), then such an exception can be easily reproduced. Such exceptions will trigger the listener exception handling and be recorded.

However, on most desktop Windows like Windows 10 I am using, _bufferSize will be 65535, not 8192 as the fragment you pasted. That's why such an issue does not happen often to draw my attention.

It would be interesting that your environment leads to a small buffer, so can you share more information about your Windows build and so on?

Using Messenger.MaxMessageSize to initialize _bufferSize (I guess that's what you chose) might be an option, but I am checking if there can be a better way.

Original Posted Date: 2016-06-25T06:46:30.637-07:00

[lextudio-support]

Copied from CodePlex without authors:

Hello,

Windows 7 Professional Service Pack 1
.net 4.6.1
application target .net 4.5

Using Messenger.MaxMessageSize to initialize _bufferSize (I guess that's what you chose) might be an option, but I am checking if there can be a better way.
=> exact.

Regards,
Rémi

Original Posted Date: 2016-06-27T02:02:50.277-07:00

[lextudio-support]

Copied from CodePlex without authors:

Thanks. I can confirm on Windows 7 the _bufferSize value would be 8192. Will do more investigation.

Original Posted Date: 2016-06-27T22:03:50.46-07:00