Enhancement: add operator==, localPort, remoteIP and remotePort to EthernetClient #1700
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.
EthernetServer doesn't provide any way to distinguish clients returned by Server.available() which makes it impossible to implement a Server that handles multiple persistent connections.
I added an operator == to allow this. It checks whether both Clients are assigned with the same socket-register by comparing _sock.
This will not recognize a change in the connection the socket-register handles. So in case the sketch stores a EthernetClient-reference and this clients connection is closed and reconnected by the W5100 you cannot detect this in your sketch by relying on the ==-operator.
To allow detection of this 'client became reconnected'-issue I've added methods localPort, remotePort and remoteIP. I have not includet localPort,remotePort and remoteIP in ==-operator to avoid unnessesary increase in memory-foodprint of the Client-object.
The updated AdvancedChatServer-example demonstrates the use of the ==-operator by distributing incomming messages to all clients but the one the message comes from. (The former ChatServer echos the messages back to the sending client).