next topic »

[on:]

Hello all,
I found a problem with the Arduino's Ethernet library.
Actually you cannot differentiate the clients input, and with the w5100 tcp hardware stack there are four socket that can send data.
From this link http://www.panu.it/MyEthernet/MyEthernet.zip you can download a modified Ethernet library with a new function

int id()

on the Client class, that return the socket number associated with the Client.
Threre is also an example TelnetServerOK modified from this code
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1278686415
which use the new function.
I hope this could be inserted in the official Arduino ethernet library.
The differences in the code are near the //MyEthernet token.
Thanks.

Alberto Panu

[Reply #1 on:]

What is the goal you had in mind? The purpose? That is always important to know.

int id()
on the Client class, that return the socket number

As it returns the socket number why not call it   int socketNumber();  ??

int x = Client.socketNumber();
Serial.println(x);

my 2 cents,
Rob

[Reply #2 on:]

The operating system use "SourcePort" to different connections, which is layered on TCP.


The method could be socketId()

[Reply #3 on:]

The method could be socketId()

And you underlined Source Port ????

socketId() is better than just ID as it is more descriptive. Other name could be localPort() as the opposite of remotePort()

Rob

[Reply #4 on:]

The method could be socketId()

And you underlined Source Port ????

socketId() is better than just ID as it is more descriptive. Other name could be localPort() as the opposite of remotePort()

Rob

Sorry Rob, I should have explained better.
I mean "socketId()" for logical id (1, 2, 3, 4)  since the hardware only supports up to four connections.
I do not know how Source Port is being implemented, I believe the ethernet chip in the shield that do it automatically or the library. Anyway, probably will not be 0, 1, 2, 3, 4. And yes very random values.

[Reply #5 on:]

I have a few more suggestions for Ethernet improvements.

1.  add functions that allow you to build or parse UDP packets in 'chunks' so that you don't have to malloc 1500 bytes of RAM to build (or parse) a packet.

one way to do this is to split up the 'recv_data_processing' and 'send_data_processing' functions in W5100Class into 3 parts. 

The first part would simply return the 'ptr' value, i.e. "return readSnRX_RD(s);" (for receive) where 's' is the SOCKET parameter passed to the function.  This function would be called when you begin creating or parsing the packet.

The second 'middle' part would use 'read_data' or implement write similar to 'send_data_processing'.  You would call this function multiple times for each 'chunk' of a packet, passing a reference to 'ptr' so that it can be updated.

The third function would then update the W5100's register with the new 'ptr' value, i.e. "writeSnTX_WR(s, ptr);" (for send).  You would call this function once when you are ready to send or finished reading a packet.

The caller would then invoke the appropriate 'Cmd' function separately (similar to the way 'recvfrom' and 'sendto' work).


2.  Replace _ALL_ occurrences of 'private' in the class definitions with 'protected' - this way you can create a derived class that has access to the (otherwise) "inaccessible" data members.  Rather than renaming the library and re-writing the whole thing yourself, you can simply derive your own class to do specialized things.  Oh, same change on everything else, too, kthx.  Tying programmer hands via private class members on an embedded platform is just silly.  'protected' has the same connotation as 'private' (as in 'leave it alone unless you know what you are doing') but removes the use restriction for derived classes.  It's a much better way to do things anyway.

3.  complete socket support (like in the UDP class) by adding a parameter 'uint8_t sock=0' (or similar) to functions that hard-code the socket to 0.  This allows existing code to work, and new code to specify a socket other than zero.


NOTE:  I came up with '1' while writing a decent DHCP implementation as a superclass of 'EthernetClass'.  '2' gave me problems, forcing me to make a copy of the library as 'MyEthernet' so I could fix it.  '3' was just an observation.

[Reply #6 on:]

I uploaded the text of my changes for '1' (above) at this web site:

http://mrp3.com/arduino.ethernet.change.txt