I understand that a server has to listen for a client, no argument with that. But the coding confuses me....
Listening for a client isn't the same as being a client, and my take on the EthernetClient() function is that it makes the shield act as a client. This line:
EthernetClient client = server.available();
.... seems to establish the shield as a client in the server sketch, but the browser is the client though, I thought....
Obviously I have this wrong, since the standard sketch works 8) so I'd be mega-grateful if someone could clarify please.
I understand that a server has to listen for a client, no argument with that. But the coding confuses me....
Listening for a client isn't the same as being a client, and my take on the EthernetClient() function is that it makes the shield act as a client. This line:
EthernetClient client = server.available();
.... seems to establish the shield as a client in the server sketch, but the browser is the client though, I thought....
Obviously I have this wrong, since the standard sketch works 8) so I'd be mega-grateful if someone could clarify please.
TIA,
Jim
I think you will find the ethernetclient object is the interface that the server has with the remote client and its browser. Using the ethernetclient object your sketch is able to extract an act upon the distant client's html request. Likewise when your sketch writes to an ethernetclient it is sending html code to the distant remote client and its web browser.
Your sketch is effectively the web server and to talks to distant web browsers via ethernetclient objects that have lives only as long as it takes to read the clients html request and send an html response (page).
'Server' names the machine that opens a socket to accept tcp-connections. (That is the arduino running the WebServer sketch).
'Client' names the interface that is used to talk to an established tcp-connection regardless from which side this connection was initiated. For your understanding: as soon a tcp-connection is established both ends are equivalent and a client or server-role no longer exists for that connection. The only method in Client-class that is specific to the role of a client (the machine that sends the SYN-package to initiate a new tcp-connection to an open listen-socket) is 'connect(...)'. So please accept that 'Client' is just a name in this case.
It might have been wise to separate Client.connect() from the other methods into a 'Connection' interface or something like that. But that has not been done when designing the Ethernet API.