Quote:
Originally Posted by Alan Anderson
I believe you are ascribing the wrong cause to what you saw. VxWorks running on the cRIO has a single shared buffer for all incoming network communication, and that's what made your flood of UDP traffic get in the way of the TCP packets from the Driver Station. Under Windows, your UDP buffer was possibly overflowing and (correctly) discarding packets, but under Windows that wouldn't mess up network communication on any other ports.
You do need to read the incoming network data at least as fast as it is arriving, but there is no requirement for you to do it in its own thread.
|
What you say here is what I was trying to say more or less... WinSock2 handles the stress of neglecting to process the packets. It was indeed the neglect of processing the incoming packets that caused this symptom which I confirmed with Greg McKaskle, and Brian from team 118 also ran into this issue back in 2012. It may indeed be possible that you can make it where it doesn't have its own thread... you could implement some kind of hand shake solution or defer sending packets until Auton or Telop functions are being called. But these alternatives are messy implementation IMHO. NetworkTables on the other hand does not have these issues at all, and probably one of the main reasons I switched... that and the ease of use, where adding more variables manually in UDP is a real pain. I've included these
UDP_Listener.h UDP_Listener.cpp for reference where I could macro switch from UDP to Network Tables... it was so much easier working with network tables that I dropped this whole interfacing design.