Just upgraded one of our clients to our .Net 4 based code and they’re having a problem on a Windows XP machine. They are running a routine that calls to the server maybe 200-300 times in quick succession. After a time, they get an error that I’ve never seen before:
“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”
I googled this and it seems to be quite a low level winsock exception. Anyone seen anything similar before and any idea how to fix it? This was running fine on the same machine under .Net 3.5
This seems to be a very low-level and hard-to-reproduce issue. Could you create a simple testcase for us reproducing this issue and to provide a stacktrace of this exception? This will greatly help us to narrow it down and fix.
<ExceptionMessage>An exception occurred on the server: 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</ExceptionMessage>
<ExceptionStack> at RemObjects.SDK.Message.ProcessException()
at RemObjects.SDK.BinMessage.DoReadFromStream(Stream iStream)
at RemObjects.SDK.Message.ReadFromStream(Stream iStream)
at RemObjects.SDK.SuperHttpClientChannel.IntDispatch(Stream aRequestStream, IMessage aResponseMessage)
at RemObjects.SDK.ClientChannel.Dispatch(IMessage aMessage)
at QUICWSINTF.QUICWSVC.Quantel_Intf_Proxy.QuantelSendClipUpdate(QuantelClipsRow[] NewClipData)
at QUIClientLib.ClientCore.QuantelSendClipUpdate(ClipsDataTable NewClipData)
at QUIClient.frmQuantelBrowser.aj(Object A_0, ItemClickEventArgs A_1)
at DevExpress.XtraBars.BarItem.OnClick(BarItemLink link)
at DevExpress.XtraBars.BarBaseButtonItem.OnClick(BarItemLink link)
at DevExpress.XtraBars.BarItemLink.OnLinkClick()
at DevExpress.XtraBars.BarItemLink.OnLinkAction(BarLinkAction action, Object actionArgs)
at DevExpress.XtraBars.BarButtonItemLink.OnLinkAction(BarLinkAction action, Object actionArgs)
at DevExpress.XtraBars.BarItemLink.OnLinkActionCore(BarLinkAction action, Object actionArgs)
at DevExpress.XtraBars.ViewInfo.BarSelectionInfo.ClickLink(BarItemLink link)
at DevExpress.XtraBars.ViewInfo.BarSelectionInfo.UnPressLink(BarItemLink link)
at DevExpress.XtraBars.Controls.CustomLinksControl.OnMouseUp(MouseEventArgs e)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
at System.Net.Sockets.Socket.Send(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
at System.Net.Sockets.UdpClient.Send(Byte[] dgram, Int32 bytes)
at Utils.SysLogSender.Sender.Send(String ipAddress, PriorityType priority, DateTime time, String body)
at Utils.SysLogSender.Sender.Send(String ipAddress, String body)
at QUICTypes.QuSysLog.WriteLine(String message)
at System.Diagnostics.TraceInternal.WriteLine(String message)
at QUICore.SystemCore.g(String A_0)
at QUICore.SystemCore.QuantelSendClipUpdate(ClipsDataTable NewClipData)
at QUICWSVC.QUICWSVC.Quantel_Intf.QuantelSendClipUpdate(QuantelClipsRow[] NewClipData)
at QUICWSVC.QUICWSVC.Quantel_Intf_Invoker.Invoke_QuantelSendClipUpdate(IROService __Instance, IMessage __Message, IServerChannelInfo __ServerChannelInfo, ResponseOptions& __oResponseOptions)
Void ProcessException()
I have been looking into this and I was slightly inaccurate when I said that we were calling the the same function repeatedly. In fact, what we’re doing is creating an array of objects that have been changed and passing them in a single call so it would seem to have something to do with the number of rows passed in that structure. What’s odd though is that it worked fine under .NET 3.5 - this has only started to happen under .Net 4.0 (and the client assures me it worked fine under the old version) - nothing else in that area of our code changed.
I’ll see if I can reproduce it and send you a mock up. Failing that I can always work around it by passing the changes in blocks of 10 or something.
Thank you for the stacktrace.
Before you start to creating a testcase could you try to do one more thing?
Seems somewhere in QUICore.SystemCore.QuantelSendClipUpdate(ClipsDataTable) you call some method QUICore.SystemCore.g(String) (probably this is its name after obfuscation, so it might be different in the actual source code).
This method calls log method QUICTypes.QuSysLog.WriteLine(String) and there is a very minor possibility that logger you use tries to send more than 64K of data in one UDP packet.
So could you try to put this entire method into try…catch (to suppress possible exceptions not related to RemObjects SDK routines) and try to get the Winsock error once again?
This change will help us to narrow the problem even more.
You were absolutely correct. The customer has an extended logging mode switched on that dumps the entire change as XML to the trace & hence to the Syslog. As soon as it went over 64K of data it blows up. Would never have thought to look there in a thousand years!!!