PHPでWebsocketデータを処理するアルゴリズムを作成しました。Chrome / Firefoxからのデコードは問題ありませんが、サーバーからクライアント（Chrome 18、Websockets 13）へのデータ送信で常に問題が発生しています。サーバールーチンは、メッセージを受信した後、自動的に「Received」と応答します。
STDOUTが示し、WireSharkダンプが示すように（RawCapを介して取得されたデータ）、メッセージの後に他のバイトはまったくありません。WireShark / RawCapでは、何らかの理由で、サーバー->クライアントメッセージが「ACK」メッセージの下に表示されました。
私はこれについて誰かの洞察を本当に感謝します。それは私を夢中にさせています。
ダスティンオプレア
I got it. It turns out that the code that I originally adopted put a single NULL character after the newlines following the handshake-response headers, and I hadn't noticed this. It looks like a) the browser moves all of the received websocket messages through a character buffer that leaves the single NULL character at the front once the authentication-response is processed, and b) it wasn't a problem until the -next- message was received.
Flow:
1) Browser (Chrome and Firefox) receives a handshake-response with an extra NULL on the end.
2) Browser approves handshake response.
3) Browser sends a message (in this case, with a "text" opcode, not that it necessarily matters) to the server.
4) Server correctly decodes frames.
5) Server sends a message back through established websocket session.
6) Client complains about having an unexpected continuation frame.
Under some conditions, I believe that I was able to manipulate the message to suppress an error from the browser, but still did not receive the server-message in the browser.
As an example of the above, I believe that, originally, the server was sending an automatic text response of "response", and got the message above. I later changed this to "1234", and still got the message above. However, I changed this to "123", and no longer got the error, but still did not get a message event in the Javascript.
Dustin Oprea