Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Socket] Read raw stream when using Socket server (no stream) #240

Merged
merged 2 commits into from
Dec 4, 2013

Conversation

cboden
Copy link
Member

@cboden cboden commented Dec 1, 2013

Re-implementing #209 after a failed merge resolution by me where I favoured #192 instead. Socket server should be using raw socket data, not stream parsed data by using fread.

@igorw
Copy link
Contributor

igorw commented Dec 4, 2013

This PR reverts #192. Using fread caused autobahn tests to fail very oddly. Presumably this is due to some stream filters triggering, which stream_socket_recvfrom bypasses completely. However, the root cause has not been detected yet.

One of the reasons the change to fread happened initially was to potentially support SSL on the server side. The decision has been made to not support that, at least until a solution to the fread problem has been found.

@cboden will post more details about the autobahn failure...

@igorw igorw merged commit d9d92e7 into master Dec 4, 2013
@igorw
Copy link
Contributor

igorw commented Dec 4, 2013

Merged.

@igorw igorw deleted the raw-server-fix branch December 4, 2013 16:15
@igorw
Copy link
Contributor

igorw commented Dec 11, 2013

@cboden you were going to post some details. DO IT!

@igorw igorw mentioned this pull request Dec 11, 2013
@cboden cboden added the stream label Feb 17, 2014
@heruan
Copy link

heruan commented Apr 2, 2014

Using the ssl branch, I don't understand why fread won't work. I tried to use it and I get an empty string from the socket, but I don't understand why. On the other hand, I would expect stream_socket_recvfrom returning encrypted data, instead it returns false

@cboden
Copy link
Member Author

cboden commented Apr 3, 2014

@heruan Without more information I'm guessing there was an issue in the SSL handshake negotiation along the way. stream_socket_recvfrom returning false means there was an error reading from the socket.

fread should work but I was coming across a scenario where a stream filter was interpreting my raw data as some kind of format/protocol and hung my connection. So the current implementation has Stream\Stream using fread with stream filters being applied where as Socket\Connection will read the raw bytes from the socket without stream filters being applied.

@heruan
Copy link

heruan commented Apr 7, 2014

I'm afraid the issue may be related to PHP bug 65137 when using StreamSelectLoop: stream_select() seems to report available data too early on encrypted streams, therefore fread or stream_socket_recvfrom fail. I'll try with LibEventLoop and report results!

@heruan
Copy link

heruan commented Apr 7, 2014

Same result with LibEventLoop, data is reported too early on the encrypted stream and fread returns empty. Calling usleep(100000) before fread does the (awful) trick.

@cboden
Copy link
Member Author

cboden commented Aug 30, 2014

65137 was recently fixed (yay) and would have been a cause for SSL not working - we did verify this in SocketClient. Once PHP 5.6.1 comes out SSL server should be viable.

This issue could be caused by 52602. By default we're reading 4096 bytes at a time but the default buffer seems to be 8192.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants