Allow remote debugging on disconnected Windows machines

[efornara]

Fixes issues #7544 and #8064

[efornara]

I've noticed that 3.0 has the same problem. Does it make more sense to modify master so that someone can then cherry pick it for 2.1?

Also, while my patch is has the merit of being very simple, it does pollute the platform independent code with a platform specific patch. An alternative I can think of would be to rewrite the command line argument from "localhost:..." to "127.0.0.1:..." in platform/windows/godot_win.cpp. They even have the same size, so there would be no need for a static buffer: a memcpy would do. It's a bit of a hack, but it would have the advantage of keeping the platform independent code cleaner.

Any suggestions?

[Faless]

@efornara first of all, thank you for trying to fix those bugs.
I've been doing some digging and the problem is a bit more complex than this.

First, the "small deploy with Network FS" option will probably be still be affected by the bug after the patch.
More importantly though the bugs are caused by the behavior of AI_ADDRCONFIG flag in hostname resolution with some platforms.

Specifically, see here and here.

I think we should either take the approach of Chrome (disable it on windows and maybe OpenBSD) or more safely take the one of mozilla.

EDIT for clarity: Mozilla approach is to use AI_ADDRCONFIG unless the hostname to be resolved is one of localhost, localhost.localdomain, localhost6, etc

I'm still evaluating the matter, opinions are welcome.

[efornara]

Yes, it makes more sense to have a general solution at the socket level. I was mostly concerned about having the debugger working as soon as possible on my laptop :-)

This piece of documentation quoted on the chrome comment sounds concerning to me:

//       - default is AI_ADDRCONFIG ON whether the flag is set or not
//         because the performance penalty in not having ADDRCONFIG in
//         the multi-protocol stack environment is severe;
//         this defaulting may be disabled by specifying the AI_ALL flag,
//         in that case AI_ADDRCONFIG must be EXPLICITLY specified to
//         enable ADDRCONFIG behavior

Maybe I misunderstand it, but not passing AI_ADDRCONFIG might not be enough on Windows, unless AI_ALL is also specified.

[efornara]

As for which of the two, I am fairly neutral myself. Is there an active discussion going on anywhere?

The bit of documentation I quoted claims that "the performance penalty in not having ADDR CONFIG in the multi-protocol stack environment is severe", so in theory Mozilla's approach seems better, but if Chrome can get away with disabling it altogether, I think it is telling.

If anything, I am more concerned about the disabling the AI_ADDRCONFIG flags fix not being enough. I didn't go through all of prnetdb.c to find out which other flags they end up setting and if they interact somehow.

What I have a stronger opinion about is waiting and let the 2.1.3 deadline pass. In my opinion, not having debugging, profiling and scene inspection on Windows when offline for a few months would be a fairly serious problem. #8087

[Faless]

can you use #ifdef WINDOWS_ENABLED instead?

[Faless]

In my opinion, not having debugging, profiling and scene inspection on Windows when offline for a few months would be a fairly serious problem.

I share your concern, I think it's a small workaround for now that we could include in 2.1 branch while we figure out a better fix

I can transfer what we know in a dedicated issue for future reference. @akien-mga what do you think?

[akien-mga]

Sounds good to me.