Defolders,
I am trying to swap the extension-websocket for the antiquated defold-websocket, but the new websocket extension spams
"Waiting for socket to be available for reading"
to the console and slows the screen framerate to about 3fps.
I can’t imagine this is intentional. Also, does extension-websocket support the Secure WebSocket protocol (wss://)?
Thanks,
grify
That sounds like something has gone wrong, yes.
You can add the “websocket.debug = 2” in your game.project to debug what the extension sends/receives to get a better understanding of what’s happening.
Yes, it supports wss://
I think this caused a crash.
I have uploaded the _crash file but I don’t believe that it is accurate because the write data in the metadata claims 2019.
_crash.txt (50.0 KB)
Here’s the editor2 log of the last 2 hours in case it is any use:
editor2.2020-10-05.txt (94.4 KB)
Well, version 1.2.173 wasn’t released in 2019, so it’s more recent than that.
However, I’m not sure if the callstack seems like it should for a crash in the extension-websocket, since it refers to “Sound”.
One way to know, would be to remove the file, then recreate the crash, check if the file is recreated, and check the last write timestamp.
$ cat ~/Downloads/_crash.txt 09:00:07
??1.2.173fe2b689302e79b7cf8c0bc7d934f23587b268c8aDarwin18.7.0enenUSdmenginelibz.1.dyliblibc++.1.dylibFoundationAppKitCocoaOpenGLOpenALAGLIOKitCarbonCoreVideoQuartzCorelibSystem.B.dylibApplicationServicesCoreFoundationlibobjc.A.dyliblibcache.dyliblibcommonCrypto.dyliblibcompiler_rt.dyliblibcopyfile.dyliblibcorecrypto.dyliblibdispatch.dyliblibdyld.dyliblibkeymgr.dylibliblaunch.dyliblibmacho.dyliblibquarantine.dyliblibremovefile.dyliblibsystem_asl.dyliblibsystem_blocks.dyliblibsystem_c.dyliblibsystem_configuration.dyliblibsystem_coreservices.dyliblibsystem_darwin.dyliblibsystem_dnssd.dyliblibsystem_info.dyliblibsystem_m.dyliblibsystem_malloc.dyliblibsystem_networkextension.dyliblibsystem_notify.dyliblibsystem_sandbox.dyliblibsystem_secinit.dyliblibsystem_kernel.dyliblibsystem_platform.dyliblibsystem_pthread.dyliblibsystem_symptoms.dyliblibsystem_trace.dyliblibunwind.dyliblibxpc.dyliblibc++abi.dyliblibauto.dylibDiskArbitrationlibarchive.2.dyliblibDiagnosticMessagesClient.dyliblibicucore.A.dyliblibxml2.2.dylibCFNetworkSystemConfigurationCoreServicesliblangid.dyliblibCRFSuite.dylibSecuritylibenergytrace.dyliblibbsm.0.dyliblibkxld.dylibAppleFSCompressionlibOpenScriptingUtil.dyliblibcoretls.dyliblibcoretls_cfhelpers.dyliblibpam.2.dyliblibsqlite3.dyliblibxar.1.dyliblibbz2.1.0.dylibliblzma.5.dyliblibnetwork.dyliblibapple_nghttp2.dyliblibpcap.A.dylibFSEventsCarbonCoreMetadataOSServicesSearchKitAELaunchServicesDictionaryServicesSharedFileListNetFSNetAuthloginsupportTCCCoreNLPMetadataUtilitieslibmecabra.dylibCoreGraphicsCoreTextImageIOColorSyncATSColorSyncLegacyHIServicesLangAnalysisPrintCoreQDSpeechSynthesisSkyLightIOSurfaceAcceleratelibcompression.dylibCoreDisplayMetalMetalPerformanceShadersMultitouchSupportvImagevecLiblibvMisc.dyliblibvDSP.dyliblibBLAS.dyliblibLAPACK.dyliblibLinearAlgebra.dyliblibSparseBLAS.dyliblibQuadrature.dyliblibBNNS.dyliblibSparse.dylibGPUWranglerIOAcceleratorIOPresentmentDSExternalDisplay?`0@\???Y??3??>.?V0?p?:??6???,?q3??0?p?2??;???Y?0/?P?0?0Y[???\??\???\??\???\?`?\??\???\???\???\? ?\?P?\?p?\???\??\???\???\??\?p?\???\?0?\???\???\?P?\? ?\?`?\???\???\?p?\???\??\???\???\?0?Y???Y???2??Y???Y??Z?`/\???/???<??2???Z???Y??0<?`?Z??Y???\? ?@???Y??*Z??+Z???[???[?@.\??Y???Z???Y??[??<2??
2?`X2?Pb2?g2??2?@=2? 82??m2? ?6?`?O??WY??iW???D??eO?@?Z??!1?@?2?P?3??V0?@/?0T/? ^/?Pc/?Pd/??h/??l/???U? z3???Z?@?0???5???5??O?-??$.?`.???-???-?p?-??-???-?p?-?@?-???-???K??N?PN?@?E?
]\???{0d1md?qd?pd# 0 pc 0x1764db5d DSExternalDisplay _sigtramp+29
# 1 pc 0x2ec103 dmengine _ZN7dmSound8FinalizeEv+19
# 2 pc 0x3407b dmengine _ZN8dmEngine6DeleteEPNS_6EngineE+283
# 3 pc 0x37d31 dmengine _Z14dmEngineCreateiPPc+129
# 4 pc 0x381bf dmengine _ZN8dmEngine7RunLoopEPKNS_13RunLoopParamsE+95
# 5 pc 0x3809d dmengine _Z11engine_mainiPPc+109
The regenerated file: _crash2.txt (50.0 KB)
I have no idea how to read these crash logs. Is there a ref for parsing them?
The file is binary, and we do have our own “crashtool_64” to analyze it, but in fact, just looking at the file in a text editor will show you the callstack in clear text. And in this case, it still mentions the sound functions (e.g. _ZN7dmSound8FinalizeEv).
It seems you’re running this on OSX? Could you share a minimal repro case with me?
the crash only occurs when websocket.debug = 2 is in the game.project. Is the section supposed to be [project] or am I placing it in the wrong location?
For a project setting of websocket.debug = 2, you’ll put this in the file:
[websocket]
debug = 2
That worked, now I get this:
DEBUG:SCRIPT: Error: Failed verifying handshake headers:
Failed verifying handshake headers:
nnection
ERROR:SCRIPT: /main/network-manager.script:4: attempt to concatenate local 'conn' (a userdata value)
stack traceback:
/main/network-manager.script:4: in function </main/network-manager.script:2>
The server says connected though?
Perhaps you can share more of the log?
Specifically what the extension sends and receives?
Yes, the server seems happy, and it’s sending the handshake response. But something goes wrong when parsing it, and I need to see what it receives in order to debug it.
Where can I find the relevant log files?
Since that particular log was a bit spammy, I used “printf”, but unfortunately, it doesn’t show up in the editor’s output window.
A quick way to show it is to bundle the app, then run the executable from Terminal. E.g.:
$ bundle/extension-websocket.app/Contents/MacOS/extensionwebsocket
There is no extensionwebsocket folder in the MacOS folder. Here’s a zip of the macOS bundle: x86_64-darwin.zip (9.6 MB)
That is the name of the executable after building the extension-websocket project. It was just an example.
The bundle itself doesn’t help me, since I needed the communication between the app and your server.
You should be able to run it locally:
$ ./x86_64-darwin/ParryChat.app/Contents/MacOS/ParryChat
I don’t entirely understand what you mean but I use Netiquette for monitoring network activity. Here’s Netiquette’s take:
What I mean is that, since you have the setup and the issue reproducible, it’s a lot easier for you to provide the log output.
Also, since the output currently uses “printf()”, it won’t get logged unless you run it with a terminal attached.
Open Terminal, and run the application:
$ ./path/to/bundles/x86_64-darwin/ParryChat.app/Contents/MacOS/ParryChat
Here you go:
Boeing-747:~ Griffin$ /Users/Griffin/Downloads/abcef/x86_64-darwin/ParryChat.app/Contents/MacOS/ParryChat
INFO:DLIB: Log server started on port 58283
INFO:ENGINE: Target listening with name: Boeing-747.local - 192.168.4.106 - Darwin
INFO:ENGINE: Engine service started on port 8001
INFO:ENGINE: Defold Engine 1.2.173 (fe2b689)
INFO:ENGINE: Loading data from: dmanif:/Users/Griffin/Downloads/abcef/x86_64-darwin/ParryChat.app/Contents/Resources/game.dmanifest
INFO:WEBSOCKET: Registered websocket extension
Registered dhttp Extension
INFO:LFS: Registered lfs Extension
INFO:ENGINE: Initialised sound device 'default'
DEBUG:SCRIPT: DefSave: Loaded file 'config' is empty
DEBUG:SCRIPT: DefSave: There is no default file set for 'config' so setting it to empty
DEBUG:SCRIPT: DefSave: Warning when attempting to get a key 'hasWelcomed' of file 'config' the key was nil
DEBUG:SCRIPT: DefSave: Warning the file config was already loaded and will be reloaded possibly overwriting changes
DEBUG:SCRIPT: DefSave: Loaded file 'config' is empty
DEBUG:SCRIPT: DefSave: There is no default file set for 'config' so setting it to empty
DEBUG:SCRIPT: DefSave: Warning when attempting to get a key 'name' of file 'config' the key was nil
DEBUG:SCRIPT: here
INFO:DLIB: SSDP: Started on address 192.168.4.106
WARNING:WEBSOCKET: Waiting for socket to be available for reading
WARNING:WEBSOCKET: Waiting for socket to be available for reading
ERROR:WEBSOCKET: Failed to find valid key in the response headers
ERROR:WEBSOCKET: Response:
"HTTP/1.1 101 Switching Protocols
Connection"
DEBUG:SCRIPT: Error: Failed verifying handshake headers:
Failed verifying handshake headers:
nnection
ERROR:SCRIPT: main/network-manager.script:4: attempt to concatenate local 'conn' (a userdata value)
stack traceback:
main/network-manager.script:4: in function <main/network-manager.script:2>
Well, according to the specification, section 1.3, that is not a valid response header from the server.
From section 1.3:
The |Connection| and |Upgrade| header fields complete the HTTP
Upgrade. The |Sec-WebSocket-Accept| header field indicates whether
the server is willing to accept the connection. If present, this
header field must include a hash of the client’s nonce sent in
|Sec-WebSocket-Key| along with a predefined GUID. Any other value
must not be interpreted as an acceptance of the connection by the
server.
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=These fields are checked by the WebSocket client for scripted pages.
If the |Sec-WebSocket-Accept| value does not match the expected
value, if the header field is missing, or if the HTTP status code is
not 101, the connection will not be established, and WebSocket frames
will not be sent.
In this case the header field “Sec-WebSocket-Accept” is missing, and no connection should be established.
It’s still possible that the client doesn’t read enough bytes, but it really shouldn’t start verifying the header unless it got the sentinel “\r\n\r\n”.
Also, I don’t see any output like “Sent bytes” or “Received bytes”.
The extension should also output the debug level:
What version of the extension are you using?
In case you were using 1.0.0, I’ve now released a newer version 1.1.0, with the latest changes: