To make myself a little more clear: when a WebSocket client tries to establish a connection, it will send a HTTP request like this:
GET /remote HTTP/1.1
Host: 127.0.0.1:8080
Sec-WebSocket-Protocol: v1.1.main\_update
Sec-WebSocket-Key: Oa2PP7lDFszNLrv6Lpk1iA==
Sec-WebSocket-Version: 13
Upgrade: websocket
Accept: */*
Accept-Language: en-ie
User-Agent: TestWebSocket/1 CFNetwork/1128.0.1 Darwin/19.6.0 (x86\_64)
Accept-Encoding: gzip, deflate
Connection: Upgrade
But as soon as I add the ws protocol stack to my nw_listener, with something like this:
nw\_protocol\_stack\_prepend\_application\_protocol(stack, wsOptions);
The negotiation is totally automatic and I have no access to the original "GET" part containing the relative path I need to differentiate connections.
So either there is a way to still get this "nw\_listener\_set\_new\_connection\_handler" or "nw\_ws\_options\_set\_client\_request\_handler" (or anywhere else) or I have to handle the negotiation myself but then how do I upgrade my HTTP socket to become a WebSocket.
Thanks !
Daniel Tapie
Post
Replies
Boosts
Views
Activity
Thank you Matt for your detailed answer ! I tried the upgrade negotiation approach (we used to do that with GCDAsyncSocket anyway), but I was stopped by the fact that I did not know how to make my NWConnection "restart" using the new added WS protocol in its stack. I could add it, but then nothing would happen...
The problem we are having is that, under 10.15, GCDAsyncSocket seems to randomly crash after a few days (I love it when it takes days to reproduce a problem) with dispatch queue overcommit exception. So far we have not been able to determine what causes these crashes, so we wanted to take advantage of the new Network framework which, apart from that problem, works great.
OK, so making progress. I have been able to implement the negotiation to upgrade the connection and I also added the ws protocol to the stack.
It seems to work ok except that every packet I send on the connection has to be formatted as a websocket packet manually (header and all) and then the client is happy and the connection is kept open. It also looks like the ping/pong works.
Could it be that the problem is that the nw_connection is only partially upgraded and does not properly format the incoming and outgoing packets ?
Makes total sense. Thank you for the clarification Matt !
Best regards,
Daniel
Hi Quinn,
I was about to ask the same question, but the link is confusing me. We are a member of the Apple Developer Programe (so we should be considered "ADP"), but we do not sell our applications on the App Store. So I guess what the "ADP" column really means is "applications sold on the App Store", right ?
It is a little frustrating not to be able to use this feature directly while we could use it through a webpage in JS...
Thank you for confirming my thought.
Daniel Tapie
Thank you for getting back to me on this and I understand you cannot comment on this (but I can ;-), and I think it is a shame that we now have to implement our own authentication system.
P.S. On a personal note I am amazed at the number of answers you provide on a daily basis. The Apple Developer community is so fortunate to have you !
Same interface...
Thank you !
Daniel
Just so you know, we also tried with different physical interfaces and it is the same issue. The problem with your suggestion is that these are in different instances of our application (these are video player applications and we need to keep them separate for safety reasons). So they are separate processes.
We cannot use different port numbers as the controlling hardware can only talk to a specific port.
Could it be the issue that the processes are different ?
I just want to make sure I file my bug report correctly and point it in the right direction...
Thank you !
Daniel
Yes, macOS Ventura, latest developer release.
Also tried on Monterey, same thing.
But since I now know it should work, I will submit the bug report and add its number here.
Thank you Quinn, your help is much appreciated !
Daniel
Here we go: the Feedback Assistant report # is 11453147.
I included a sample project to demonstrate it inside a single app (same problem as with different apps).
Thanks !
Daniel
For me it is the same thing with every font I tried (including Arial) starting in macOS 14.2 beta 1. Still the same with beta 4.
Daniel