Client- and serverside bug fixes #94
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
merge segor's fork
Avoids null-reference exception, when underlying socket is not connected.
Used to indicate when server shuts down.
Added some settings in csproj and .gitignore.
When FastDirectSendingMode is set to true, the send-threads are not started.
Messages are then sent directly from the multithreaded application to
the underlaying socket buffer.
The Send method may block a short time
until the previous send operation has copied its data do the socket buffer.
There is a considerable speed increase for applications needing
fast roundtrip times and have a small number of clients:
FastDirectSendingMode = false: 33 request+responses per second - caused by a delay of 10ms in every dequeue operation.
FastDirectSendingMode = true: 2500 request+responses per second
Removed unused method 'DoReceive'.
Documented the strange behavour of WebSocketServer.Dispose().
Added asynchronous connect operation to client; Added LatestException to UserContext. This improves WebSocketClient connect and disconnect.
…en sending many messages in server or client.
Support partially received headers on server and client side. Fixed reset of FrameHeader.IsEnd. Fixed client disconnect (make it ready for next connect). Fixed WebSocketServer.Clients (count). Fixed and improved integration test ClientSendDataConcurrent. Added integration test ClientSendMultipleMessages.
…looping in a threadpool thread.
No need to ReceiveReady.Wait until a request has been received. Removed client side setup threads. Direct setup is faster. No need for static threads on client side. Improved integration tests.
|
Ah this fixes that weird https://github.com/Olivine-Labs/Alchemy-Websockets/blob/master/src/Alchemy/WebSocketClient.cs#L151 stuff; I'm not sure why that actually would ever work. Thanks, please merge. |
|
I've tested this fork it's running supper great, no missing packet anymore. Please merge! |
Added stream API to DataFrame. Fixed UnitTests for MonoDevelop.
FlashAccessPolicyEnabled is set through the WebSocket constructor.
Prepared stream API on DataFrame for MsgPack integration.
…arin.Android or NET 4 Client Profile. System.Net contains a compatible name-value-CookieCollection.
Added a ClientAddress update since it never got set due to Context initialization with "null,null"
Update WebSocketClient.cs
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I picked Alchemy as communication framework for my remote actor library because of Alchemys slim design and the availability of a client implementation.
But after some initial success I ran into more and more bugs, especially on the client side.
This pull request collects all committs that were needed to make the library much more stable.
When reading the list of open issues I think some of them could be fixed by this pull request too:
E.g. #93, #89, #84, #78, #72, #66, #60, #53, #49, #25
The changed points are:
Fixed errors and made it rfc6455 conformant
Fixed message loss, when several messages are received in the same TCP packet
Useful when a server must be very responsive. When setting this flag,
the maximal throughput rises from 33 to more than 5000 request/response pairs per second