API Changes #45
Merged
API Changes #45
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
Because there's no reason to keep a single file per folder. Although the history seems to be lost, it is still possible to find the old commits with 'git log --follow'.
This commit changes the use of the 'fd' parameter of the wsServer's API and replaces it with a pointer of type 'ws_cli_conn_t'. This change brings multiple benefits to the source code: a) The 'fd' could confuse the user and cause them to use it in other POSIX routines that accept a file descriptor. b) Sharing the 'fd' through various functions and iterating over the list of clients to get the structure of it sounds completely pointless. Therefore, the natural solution is to share the pointer relative to the client's connection structure, which improves code complexity, readability, and reduces the amount of LOCs. -- Furthermore, this commit also changes the way broadcast messages are sent: previously, to send a broadcast it was necessary to know the 'fd' of a valid connected client, which also doesn't make sense. Therefore, the signing of the ws_sendframe* functions has been simplified, and the 'broadcast' parameter is no longer needed. If the recipient is null, the message is a broadcast. --- Note: The multi-port listening feature has been removed in order to make the broadcast mechanism simpler. However, I intend reintroduce it in the future by removing all public variables and leaving the event frame bound to a 'struct ws_server'.
In issue #41 there was a problem getting the IP address during the onclose() event, as the server was trying to get an IP from an already disconnected client. This commit fixes this by saving the IP address of the client right during the initial stages of the connection, which makes it available at any time, even when the client is disconnected.
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.
Description
A few days ago I was asked why wsServer only sends broadcast messages if it knows a client beforehand (its 'fd'). Clearly this is an issue as the broadcast must work without the prior knowledge of any connected users.
This PR therefore fixes this bug by changing the signature of the ws_sendframe* routines: if a client is present, send only to it, otherwise broadcast.
In addition, the 'fd' parameter present in the API functions was replaced with 'ws_cli_conn_t', which made the code more intuitive and also allowed a great internal cleaning of the source code.
The new function signatures:
and the events:
A huge thanks to @tinkering4fun and @troglobytor for the discussion over the last few days on how I should approach this issue. I'm happy with the result and hope it meets your expectations.
Feel free whenever you want to suggest something... open an issue, discussion, PR... I'm always trying to listen to the community and adapt wsServer to their needs.