High Performance Driver and Socket .NET Method Calls

[Tom.Net]

I am currently developing external software that will interact with our (soon to be) GigE Vision compliant camera. I am currently using a Dalsa Genies HD camera to develop the software while awaiting hardware. 

The issue I am having is that when I install the High Performance Driver for my Intel PRO/1000 GT Desktop Adapter, my viewing software that uses the NI-IMAQdx libraries works fine, but my gigabit Ethernet communication library that uses the .NET Socket class does not actually send the bytes over the wire even though the method succeeds.

When I revert back to the stock Intel driver, my communication library works fine. A side note is that the gige communications library is tested and has been used for while now, we just recently bought the Intel NIC to increase streaming performance and hence these issues surfaced.

I can just use the stock Intel driver, but I am trying to get "Best Case" numbers to get more project funding.

A more detailed view:

The following is the line I am using to send data over ethernet:

      int bytesSent = this.socketSend.SendTo(toSend, this.DestIP);

where

     socketSend is my Socket object and DestIP holds the destination IP and port

     toSend is the byte[] of size 8

When using the High Performance Driver this method returns the number of bytes that are sent and in my case it returns 8 for a standard GigE Vision GVCP  Header (indicating a success), however Wireshark shows that these bytes never hit the wire (hence the camera does not respond and i get a timeout).

Any ideas?

Thanks for the help.

Tom

[BlueCheese · Accepted solution]

Hi Tom,

Are you sure there is not something else going on unrelated to the High Performance Driver? Can you go back and forth between the two drivers reliably and see the problem appear and disappear? Does a reboot help? Do you possibly have a filter driver in place? Wireshark itself uses a filter driver (winpcap) to capture data, and depending on how you have it start (on boot, etc) it may not be able to capture data from new drivers that are loaded after winpcap loaded. I would be suspicious that you might not be seeing traffic in wireshark due to a reason such as that.

Is it possible the Windows firewall is enabled on that port? 

Interaction between the High Performance Driver is an all-or-nothing affair, and so the .NET sockets should behave the same as any other applications do. When you are hitting this problem, can you use other programs reliably through the network connection in that case? Does ping work? 

Eric 

Message Edited by BlueCheese on 05-26-2010 03:43 PM

[Tom.Net]

Thanks Eric for the help.
 

“Are you sure there is not something else going on unrelated to the High Performance Driver?
Can you go back and forth between the two drivers reliably and see the problem appear and disappear?”

Yesterday I could replicate this every time, but this morning I switched back to the NI High Performance driver and the .NET Sockets worked fine. I did NOT reboot this morning either.
 

“Does a reboot help? “
Not that I have seen. I have tried this with no conclusive results.

 
“Do you possibly have a filter driver in place? “
No, well not that I am aware of.

 

“Wireshark itself uses a filter driver (winpcap) to capture data, and depending on how you have it start (on boot, etc) it may not be able to capture data from new drivers that are loaded after winpcap loaded. I would be suspicious that you might not be seeing traffic in wireshark due to a reason such as that.”

Great point! That would easily explain wireshark not picking up the packets and there may be a bug in the GigE communications where the packet is going out, but I am not getting it for some reason.

 
“Is it possible the Windows firewall is enabled on that port? “

Windows firewall is not enabled at all, but we do have some Symantec tool running that I am unable to disable. At this company our IS department (supposed to stand for Internet Security, but should be called Internet Shutdown), they run all sorts of “tools” that destroy performance, especially over the Ethernet port. I would not be surprised if that is causing some of the issues I am seeing, unfortunately I need to prove without a doubt that it is in fact causing these (and other)  issues.

 
“Interaction between the High Performance Driver is an all-or-nothing affair, and so the .NET sockets should behave the same as any other applications do. When you are hitting this problem, can you use other programs reliably through the network connection in that case? Does ping work?”

Since I am unable, at the moment, to replicate this(*arg…) I can not try. If I run into this again, I will check.