• UnderSampled (unregistered)

    After considering our options, we decided this was a good case for Unity and C#. After a quick test of doing multitouch interactions, we also decided that we shouldn't deploy to Linux (Unity didn't really have good Linux multitouch support), so we would deploy a Windows kiosk.

    You could have used Godot!

  • Foo AKA Fooo (unregistered) in reply to MiserableOldGit

    As I read it, it hung while resolving the address which as noted is a bit unclear, but seems to refer to ARP. Since that never finished, the packet was never sent. (If it was, all would be fine, as in UDP that's all that happens, so if the client doesn't send a reply, you'll never know whether it received it.)

    The hub (or more likely switch, I guess) doesn't even come into play here, it's all on the Windows computer. (If it was on the hub/switch, all would be fine too, since any hub/switch worth its name has a proper networking stack. It certainly won't hang for 3 seconds waiting for an ARP reply for every single packet serially.)

    No to reCAPTCHA: If you keep annoying me with too many screens, I'll give you random data to poison your DB. Mission accomplished.

  • MiserableOldGit (unregistered) in reply to Foo AKA Fooo

    Yeah, I didn't mean hub in the network sense, I just meant the centre of this thing, where the packets are being sent from, the main application. I was using a wheel metaphor, slap me for sloppy terminology!

    The way it was written suggested to me it was flooding packets out anyway and the process was hanging waiting on some sort of ARP response (or rather 3 sec timeouts), doesn't seem to make sense that the networking would be overwhelmed with useless UDP, but the windows computer getting gummed up waiting for thousands of three second waits to complete does. But I'm far from knowledgeable on the intricacies of low level networking or (I suppose in this case) how APIs deal with it.

  • Old timer (unregistered)

    I just use broadcast -- the clients only have to read an Id value (or a port number), I don't need to know the client MAC. There is a problem because IPV4 broadcast storms don't work very well with multi-homed computers -- it's tricky to specify a specific adapter, and different on different platforms -- but in this case we already know that the patron won't be networked.

    If I had to do it on a networked computer, and didn't want to fix the code, I'd use a Win version that allows loopback connectors so that I could specify a gateway, or ... put a gateway device in the kiosk cabinet, it adds, what $100 to the price, plus an extra plug pack. Really. I use an isolating switch all the time (for other reasons), and using a router for isolation instead of a switch wouldn't phase me at all.

  • Charleh (unregistered)

    Am I the only one that can't see the point of projects like this? All that for a chandelier? Sounds like a massive waste of time to me.

  • Jim (unregistered)

    Well, when you don't care to do it properly and don't care to learn a little about the framework/api/os you are using, why do you care whether it works or not?

    My only hope is that the installers that hanged the damn thing DID care so it won't kill anybody.

  • codedr (unregistered)

    I worked on a software installation on a windows install acting as a server. The software received a network request over tcp/ip, processed the results, and returned the reply, almost immediately. The client dies, not ever getting a reply, after a timeout of 5 seconds. (5 second tcp/ip timeout is another WTF) The logs on the server show that the reply is (nearly) immediate. Fortunately we are able to get a network trace log, and it shows the reply going out after 30 seconds on the network stack. After a lot of investigation, including blaming network intrusion software and virus scanners, found a old windows protocol 'WINS' (?) [I forget the exact acronym] that was doing a windows lookup via the network 'What kind of windows software are you.' which would not get a reply, because the client was running linux. After 30 seconds, it would timeout and send the packet, that the client did not care about any more. Removing/disabling WINS in the network stack fixed the issue.

  • (nodebb)

    "Usually, it's just a matter of finding out what object references are still being held" -- If there is an object reference, it is NOT a memory leak.... sure it is unintended consumption, but it has not LEAKED (become unreachable, "not contained in allocation map")

  • Game Developer (unregistered)

    That's Unity for you. Heisenbugs like this are the reason why I've moved to Godot. And now I am happy.

  • (nodebb)

    Since this was just linked to by todays article....There are definitely references that live much longer than needed in many (most) .NET programs (and other GC environments). However as long as it is POSSIBLE to reference the object it is NOT a memory leak... PERIOD, EOS.

    You have a list, one item has a datatable that was really only used for load, and that is part of a dataset and you are holding 10GB of objects in memory because of that unneeded reference.... NOT A MEMORY LEAK.

  • Lucero (unregistered)

    The WTF here is that you use a screwdriver to hammer a nail - use the right tool for the job instead.

    You should use the Sockets class directly, set the Blocking property to false, and the send off your UDP packets using SendTo() using the DontRoute flag if the receiver is expected to be on the local network. This has all been there since .NET Framework 1.1 and still exists in .NET 5...

  • Remy No (unregistered)

    Remy, sorry, but this one is entirely on you. First, you had fundamental misunderstanding of async programming in .NET. The major takeaway is that the async keyword most likely doesn't spin up a thread or have anything to do with them. Second, executing async functions without awaiting is an antipattern and leads to various issues, subtle or not. HERE BE DRAGONS! That's what you said by doing so. So I am not surprised in the slightest that you couldn't wrangle the beast and had to resort to workarounds.

Leave a comment on “A Massive Leak”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article