Hello, I seem to be having a little problem with OutGauge and i need some assistance . Im using .Net UdpClient to connect to OutGauge( as a pose to System.Net.Sockets.Socket ). My problem is, I receive a few packets and then the socket just "hangs". Look at the attached picture. I clicked Connect on the win form, In the Debug display at the bottom it received 3 packets detailing that i was in a XRR. As you know that should be consistant. The line it seems to be stopping on is the followng...


The code before that, (RemoteIpEndPoint):


Now, To my knoledge that should work, but for some reason it doesnt. Any help would be much appreciated

Without investigating further (having a crappy day, so forgive me), and without reading thoroughly, have you checked our socket isn't reaching timeout?

Quote from JamesF1 :

Without investigating further (having a crappy day, so forgive me), and without reading thoroughly, have you checked our socket isn't reaching timeout?

Doesnt appear to be, There is only about 8 seconds between starting the program then connecting and then it stoping working.

In a similar mood as James, I would also check you're not consuming more bytes than intended and thus setting the stream out of sync

Quote from BurnOut69 :

In a similar mood as James, I would also check you're not consuming more bytes than intended and thus setting the stream out of sync

Just checked that, Doesnt seem to be that neither. Bytes are coming in OK. It just seems to be waiting on the UdpClient.Receive() after anything between 1-5 packets come in(Totally random).

Give us a bigger section of the code, let's see what's going on.

Thats the 2 main methods, Or atleast should be all the info you need to know, also, Any improvment suggestions - Dont flame Help me.

E: Writing it directly to a global buffer prolly isnt such a good idea, but seen as there is only ever one packet, I dont see that it matters..

E2: vBulletin sucks as a C# ide...

This is a long shot, but maybe its being more like C and not so # (sharp) in that your Rcv_Buffer already has random data in it. In C this would be solved by memset, which sets all bytes to 0. I dunno much about C# but my guess is this is done implicitly but ya never know, I certainly don't

Quote from Stuff :

This is a long shot, but maybe its being more like C and not so # (sharp) in that your Rcv_Buffer already has random data in it. In C this would be solved by memset, which sets all bytes to 0. I dunno much about C# but my guess is this is done implicitly but ya never know, I certainly don't

Well, If that was the case then the only problem would be marshalling it from packets to struct. I dont see how that could stop it receiving packets..

Quote from Stuff :

This is a long shot, but maybe its being more like C and not so # (sharp) in that your Rcv_Buffer already has random data in it. In C this would be solved by memset, which sets all bytes to 0. I dunno much about C# but my guess is this is done implicitly but ya never know, I certainly don't

There's no need for a memset equivalent in C#, in this case

Quote from JamesF1 :

There's no need for a memset equivalent in C#, in this case

Bit of a mystery eh?

Just to clear up the UDP confusions (if it still exists);

Quote from BurnOut69 :

In a similar mood as James, I would also check you're not consuming more bytes than intended and thus setting the stream out of sync

Quote from mcgas001 :

E: Writing it directly to a global buffer prolly isnt such a good idea, but seen as there is only ever one packet, I dont see that it matters..

There isn't a stream in UDP (because it's connectionless), so packets come across independently.

As you know, I'm not a .NET man, but is there any chance that the UDPclient is doing something funky?

From what I can see there's little benefit to using it over the bog standard sockets?

I've never used UdpClient really, but I'd suggest changing the code to use a normal Socket to see if the problem still occures.

Something like this, although note this is untested.


It does the same basic thing, so if it still hangs you know the problem is somewhere else, not the UdpClient.

Quote from the_angry_angel :

Just to clear up the UDP confusions (if it still exists);
There isn't a stream in UDP (because it's connectionless), so packets come across independently.

Thats so right Im embarrassed.

One suggestion to mcgas, though: I strongly recommend to set the priority of the thread to below normal, otherwise it will suck cpu big time. In my rusty AMD it was VERY noticeable.

It should only suck CPU time if the Receive call isn't blocking properly, then the while(true) loop just goes like the crackers. If the loop if working correctly then the CPU effect from the receive calls should barely even register on TaskManager. I have a little race logging app using InSim, even on 30 car races with MCI intervals set to 50 milliseconds, it doesn't even reach 1% load on any core of my CPU.

I think when I was messing around with OutSim I had the same, or at least a similar problem. Switching from UdpClient to using Sockets mysteriously solved it.

Quote from AndroidXP :

I think when I was messing around with OutSim I had the same, or at least a similar problem. Switching from UdpClient to using Sockets mysteriously solved it.

Hasnt with me. Although now, it doesnt even receive one packet. It just blocks indefinitely....

E: Its acutally rather strange. Sdthers LFSLib and example OutGauge app works....

For the record, I have now fixed this. I was trying to connect and yet UDP is connectionless. Silly me...

But, Thanks to T-RonX as he showed me that i had it wrong.

Quote from mcgas001 :

I was trying to connect and yet UDP is connectionless. Silly me... .

Well that was smart :dunce:

Quote from JamesF1 :

Well that was smart :dunce:

LOL!, Didnt see you notice it neither