Pages: 1 ... 3 4 [5] 6 7 ... 9   Go Down
Author Topic: Thumbs way down for Arduino WiFi shield. Read before you buy  (Read 13523 times)
0 Members and 2 Guests are viewing this topic.
Miramar Beach, Florida
Offline Offline
Faraday Member
**
Karma: 115
Posts: 5380
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Here is my example web client sketch for the wifi shield. It has been running for a while without a fail.
http://forum.arduino.cc/index.php?topic=200784.0

I have tried all I know to get it to fail, and it is still running. At 30 seconds per request, it has sent over 4300 requests. I have disabled the wifi router radio, broken the connection with the ethernet to the router, stopped the server, etc. It still runs fine.

If you could try that code and let me know how it works for you, that would help me out. If it works for more users than just me, I will add it to the playground.
Logged

Emsworth, UK
Offline Offline
Full Member
***
Karma: 6
Posts: 181
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote from: SurferTim
So much for 2 second delays between sends.
Sigh:  I sometimes wonder about the attitude displayed on these forums smiley-sad

Quote
My first try was my basic UDP packet send. I have it set to 48 byte packets at 10 packets per second, and it is doing fine!
Did you consider perhaps your test failed to find the 2 second latency. 
I note your web server is not responding very quickly.  Why would that be, do you think?

Logged

Miramar Beach, Florida
Offline Offline
Faraday Member
**
Karma: 115
Posts: 5380
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote from: SurferTim
So much for 2 second delays between sends.
Sigh:  I sometimes wonder about the attitude displayed on these forums smiley-sad

Quote
My first try was my basic UDP packet send. I have it set to 48 byte packets at 10 packets per second, and it is doing fine!
Did you consider perhaps your test failed to find the 2 second latency. 
I note your web server is not responding very quickly.  Why would that be, do you think?
You can't just say "2 second latency" without being a bit more specific. If it is only the send on the server, then you may be correct about a delay, but I don't see 2 seconds. And certainly no latency on UDP.

Did you find the socket error in the wifi server library yet? I have. I haven't had time to correct it yet. I'll get to it after the client sketch is debugged.

I also found a socket error in the client library, but have a patch for it already. It is working ok. I'm up to 5500+ requests and no socket loss and still running fine, no matter what I do to it. No 2 second latency there.
Logged

Miramar Beach, Florida
Offline Offline
Faraday Member
**
Karma: 115
Posts: 5380
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Enough testing of the client sketch. Over 7000 requests without a socket problem. That is good for me.

Here is the server socket problem. The first socket check is correct, but all others are not. If the socket shows -1, the socket is available. If the socket shows the socket number (0-3), it is used by the server.  It appears it is using only one socket, and after the first request, there is no socket used by the server to listen on port 80.
Quote
Starting SD..ok
Firmware version: 1.1.0
Attempting to connect to open SSID: OhSh
You're connected to the networkSSID: OhSh
BSSID: 0:C:42:2B:B8:B4
signal strength (RSSI):-44
Encryption Type:4
IP Address: 192.168.0.9
192.168.0.9
MAC address: 7A:C4:E:1C:AF:F8
NetMask: 255.255.255.0
Gateway: 192.168.0.1
Ready
// this is correct.
0  80
-1  0
-1  0
-1  0


Client request #1: GET / HTTP/1.1
file = /
file type =
method = GET
params =
protocol = HTTP/1.1
Home page SD file
filename format ok
SRAM = 6083
file found..opened..send..closed
disconnected
//this is bad. No socket listening.
-1  80
-1  0
-1  0
-1  0


Client request #2: GET /defcss.css HTTP/1.1
file = /DEFCSS.CSS
file type = CSS
method = GET
params =
protocol = HTTP/1.1
SD file
filename format ok
SRAM = 6083
file found..opened..send..closed
disconnected
// and this is bad. Still no socket listening.
-1  80
-1  0
-1  0
-1  0


This is how it should look. Note there is always an active socket listening on port 80.
Quote
Starting SD..ok
Firmware version: 1.1.0
Attempting to connect to open SSID: OhSh
You're connected to the networkSSID: OhSh
BSSID: 0:C:42:2B:B8:B4
signal strength (RSSI):-44
Encryption Type:4
IP Address: 192.168.0.9
192.168.0.9
MAC address: 7A:C4:E:1C:AF:F8
NetMask: 255.255.255.0
Gateway: 192.168.0.1
Ready
// socket 0 listening
0  80
-1  0
-1  0
-1  0


Client request #1: GET / HTTP/1.1
file = /
file type =
method = GET
params =
protocol = HTTP/1.1
Home page SD file
filename format ok
SRAM = 6083
file found..opened..send..closed
disconnected
// socket 1 listening
-1  80
1  80
-1  0
-1  0


Client request #2: GET /defcss.css HTTP/1.1
file = /DEFCSS.CSS
file type = CSS
method = GET
params =
protocol = HTTP/1.1
SD file
filename format ok
SRAM = 6083
file found..opened..send..closed
disconnected
// socket 0 listening
0  80
-1  80
-1  0
-1  0

It appears it is using only one socket, and after the first request, there are no sockets used by the server.

edit: I highlighted the socket checks in bold type so they are easier to see.

The first thing the server should do when detecting a client connected to the active socket is start another socket listening for the next client on the first available socket.
« Last Edit: November 26, 2013, 06:59:52 am by SurferTim » Logged

Emsworth, UK
Offline Offline
Full Member
***
Karma: 6
Posts: 181
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote from: SurferTim
You can't just say "2 second latency" without being a bit more specific.

I agree, which I guess is why I was pretty specific about it.
 http://mssystems.emscom.net/helpdesk/knowledgebase.php?article=51
I don't mind that you might not read it or might not understand it.  I only mind you presumed to know better.

Quote
If it is only the send on the server, then you may be correct about a delay, but I don't see 2 seconds. And certainly no latency on UDP.

I disagree with your use of the word 'only.' 

You will not see the 2 second delay using 10 x 48 byte packets.  Write an uninterrupted stream > ~2.75KB and the delay becomes evident.  The transfer speed is effectively throttled at ~12Kbps, about the same as a 17 year old modem.

Quote
Did you find the socket error in the wifi server library yet?

Was I supposed to be looking for it?  I pretty much decided an SoC with a 5 Euro WiFi adapter is a less expensive fix.

Quote
I also found a socket error in the client library, but have a patch for it already. It is working ok. I'm up to 5500+ requests and no socket loss and still running fine, no matter what I do to it. No 2 second latency there.

To be fair  to you, I thought I better have a go with your client.   Admittedly I got a bit bored waiting out the 30 second polling interval and changed it to 15 seconds.  I also added a byte counter and sampled the time the client spent in the receive loop.

Of those 5500 requests, did you check the byte count on all of them?  I suspect not.

Code:
Ready
Socket #0: available
Socket #1: available
Socket #2: available
Socket #3: available
connecting...connected
Socket #0: used
Socket #1: available
Socket #2: available
Socket #3: available
HTTP/1.1 200 OK
Date: Tue, 26 Nov 2013 14:46:53 GMT
Server: Apache/2.2.24 (PCLinuxOS 2011/PREFORK-1pclos2013)
Last-Modified: Sun, 24 Nov 2013 10:49:09 GMT
Accept-Ranges: bytes
Content-Length: 43
Connection: close
Content-Type: text/html

<html><body>test server page</body></html>
TotalBytes = 290 in 1341 ms

disconnecting.
Pass 1
Socket #0: available
Socket #1: available
Socket #2: available
Socket #3: available
connecting...connected
Socket #0: used
Socket #1: available
Socket #2: available
Socket #3: available
TotalBytes = 0 in 1091 ms

disconnecting.
Pass 2

So that's one uncaught failure and a one successful 290 bytes in 1.341 Seconds; a whopping 1.75Kbps!

A 16 character payload is not what I call a fair test.  Small pages will reduce throughput and you don't come across them too often in real life.  So I thought I might try against one of my own web servers, on my local net.  Your client took 4.253 Seconds to read 4109 bytes at 7.73Kbps!  The default Apache page, 5240 bytes in 4901 ms at 8.6Kbps. 

Still not breaking that 12Kbps bottleneck then.

A 404 not found proved interesting, 470 bytes in, between 1022ms to 2065ms. The 404, a small page like your test page, failed more times than it succeeded, returning 0 bytes in ~1700ms.

Hmm, it looks very much to me as if the shield's buffers might be ~ 2.75KB, are serviced at ~2 second intervals and when the connection is stopped before the buffers have been serviced, data is silently discarded.

Logged

Miramar Beach, Florida
Offline Offline
Faraday Member
**
Karma: 115
Posts: 5380
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Actually, my first download test was Google's home page. It is rather large, and downloads at just about the serial bus speed.

The WiFi.getSocket() call is dependent on the values in the WiFi._state array. That is the array affected in the server code that I described above. If you fire up the server code and make one request, from then on out, the WiFi.getSocket() function call will return 0, at least the first call. That is due to the socket malfunction I also described above. Since the server does not reserve a socket for the listener, it gets the first socket with the WiFi._state[] value of -1. That will be socket 0, since all the sockets are showing a state of -1 (available) in that array after the first client request.

I will check that to verify the getSocket() return value, but it should always be socket 0 the first call. I will check what happens when the server is running and calling that function.

edit: I looked at the getSocket() and server code again. It is the WiFi._server_port[] array that is used by getSocket(). Then that verifies the server uses only one socket. The only socket that has a non-zero WiFi. _server_port[] is socket 0, no matter how many requests are made.
Code:
uint8_t WiFiClass::getSocket()
{
    for (uint8_t i = 0; i < MAX_SOCK_NUM; ++i)
    {
        if (WiFiClass::_server_port[i] == 0)
        {
             return i;
        }
    }
    return NO_SOCKET_AVAIL;
}
I checked with my server code,and WiFi.getSocket() always returns 1.
« Last Edit: November 26, 2013, 01:02:28 pm by SurferTim » Logged

Miramar Beach, Florida
Offline Offline
Faraday Member
**
Karma: 115
Posts: 5380
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

@MattS-UK: I see the delay now, but only on large file transfers, and not 2 seconds in my case. More like a second, but that is still too long. According to my tests, this is where the delay happens. This function is in /utility/server_drv.cpp. If it waits for a timeout, it could be 2.5 seconds (delay(100) x 25)
Code:
uint8_t ServerDrv::checkDataSent(uint8_t sock)
{
const uint16_t TIMEOUT_DATA_SENT = 25;
    uint16_t timeout = 0;
uint8_t _data = 0;
uint8_t _dataLen = 0;

// it happens in this do-while loop.
// Uncomment the 3 Serial.print() commands to check it.
// It prints an exclamation point before the loop, and an asterisk after the loop.
// The last character printed on the serial monitor is an exclamation point during the delay.

//   Serial.print("!");
do {
WAIT_FOR_SLAVE_SELECT();
// Send Command
SpiDrv::sendCmd(DATA_SENT_TCP_CMD, PARAM_NUMS_1);
SpiDrv::sendParam(&sock, sizeof(sock), LAST_PARAM);

//Wait the reply elaboration
SpiDrv::waitForSlaveReady();

// Wait for reply
if (!SpiDrv::waitResponseCmd(DATA_SENT_TCP_CMD, PARAM_NUMS_1, &_data, &_dataLen))
{
WARN("error waitResponse isDataSent");
}
SpiDrv::spiSlaveDeselect();

if (_data) timeout = 0;
else{
++timeout;
delay(100);
// Serial.print("+");
}

}while((_data==0)&&(timeout<TIMEOUT_DATA_SENT));
//   Serial.print("*"');

    return (timeout==TIMEOUT_DATA_SENT)?0:1;
}

Here is the function called in that loop. It is in /utility/spi_drv.cpp. I'm not sure I understand the CHECK_DATA calls.
edit: They are probably a define somewhere, but I don't have time to search for them right now.
Code:
int SpiDrv::waitResponseCmd(uint8_t cmd, uint8_t numParam, uint8_t* param, uint8_t* param_len)
{
    char _data = 0;
    int ii = 0;

    IF_CHECK_START_CMD(_data)
    {
        CHECK_DATA(cmd | REPLY_FLAG, _data){};

        CHECK_DATA(numParam, _data);
        {
            readParamLen8(param_len);
            for (ii=0; ii<(*param_len); ++ii)
            {
                // Get Params data
                //param[ii] = spiTransfer(DUMMY_DATA);
                getParam(&param[ii]);
            }
        }        

        readAndCheckChar(END_CMD, &_data);
    }    
    
    return 1;
}

edit: I added a comment in the code to show how I checked it if you are interested.
edit2: I also added a Serial.print("+") inside the do-while loop. During the delay, I get a string of "++++++++++++++++++".

« Last Edit: November 28, 2013, 05:59:50 am by SurferTim » Logged

Miramar Beach, Florida
Offline Offline
Faraday Member
**
Karma: 115
Posts: 5380
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

@MattS-UK: I changed the code in the library as in the post above and did a new test, and found we are both correct. The delay is 1 second and 2 seconds, depending on which side of the router's masquerade the client is on.

If I request the page from a local interface on my router (ethernet), the delays are 1 second (10 to 12 '+'). If I request the page from the internet interface, the delays are 2 seconds (19 to 20 '+').

edit: Whoa! Here is a shocker! Somebody just downloaded the waterfal.jpg image from the internet, and the delays were minimal (2 to 3 '+'). And it was fast enough to not timeout on the favicon.ico.

Same client just downloaded the soccer image (wolver.jpg) with the same 2 to 3 cycles in the delay, and fast enough to get the icon. ??
« Last Edit: November 28, 2013, 07:06:30 am by SurferTim » Logged

Miramar Beach, Florida
Offline Offline
Faraday Member
**
Karma: 115
Posts: 5380
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Somebody just downloaded the soccer image in record time. Only one 100ms delay where everyone else is 1 to 2 seconds. Who are you? Could this be browser related?

edit: Again somebody downloaded the waterfall image with only one 100ms delay at what is 1 to 2 seconds for others. ??
And another downloaded the soccer image with only 100ms delays.
« Last Edit: November 28, 2013, 10:28:42 am by SurferTim » Logged

Miramar Beach, Florida
Offline Offline
Faraday Member
**
Karma: 115
Posts: 5380
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Another user is downloading the images well. This time the first delay is about a second, but the following delays are only 100ms each. Who are you ? What browser are you using?

edit: Each waterfall image download has about a dozen separate delays during the download. The soccer image has a few more that that. 12 times 2 seconds (24 seconds delay) is horrible. 12 times 100ms (1.2 seconds) is bearable.

Here is what I see on the serial monitor. Each "!*" pair is a packet. Each "+" is a 100ms delay. Here is the last request/download.
Code:
Client request #44: GET /IMG/WATERFAL.JPG HTTP/1.1
file = /IMG/WATERFAL.JPG
file type = JPG
method = GET
params =
protocol = HTTP/1.1
SD file
filename format ok
SRAM = 6075
file found..opened..!*send..!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!+++++++++++++++*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!+*!*!*!
*!*!*!*!*!*!*!*!*!*!*!*!*!+*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!+*!*!*!*!*!*!*!*!*!+*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!+*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!+*!
*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!+*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!+*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!+*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!+*!*!*!*!*!*!*!*!*
!++*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!+*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!+*!*!*!*!*!*!*!*!*!+*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!+*!*!*!*!*!*!*!*!*!*!*!*!*!*!
*!*!+*!*!*!*!*closed
disconnected

Here is what my download looks like.   smiley-sad
Code:
Client request #50: GET /IMG/WATERFAL.JPG HTTP/1.1
file = /IMG/WATERFAL.JPG
file type = JPG
method = GET
params =
protocol = HTTP/1.1
SD file
filename format ok
SRAM = 6075
file found..opened..!*send..!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!+++++++++++++++*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!+++++
+++++*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!+++++++++++*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!++++++++++*!*!*!*!*!*!*!*!*!+++++++++++*!*!*!*!*!*!*!*!*
!*!*!*!*!*!*!*!++++++++++*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!++++++++++*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!++++++++++*!*!*!*!*!*!*!*!*!*!*!*!*!*!
*!*!*!++++++++++*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!++++++++++*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!++++++++++*!*!*!*!*!*!*!*!*!++++++++++*!*!*!*
!*!*!*!*!*!*!*!*!*!*!*!*!++++++++++*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!++++++++++*!*!*!*!*!*!*!*!*!++++++++++*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!+
+++++++++*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!++++++++++*!*!*!*!*closed
disconnected
« Last Edit: November 28, 2013, 11:22:53 am by SurferTim » Logged

Emsworth, UK
Offline Offline
Full Member
***
Karma: 6
Posts: 181
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

@MattS-UK: I changed the code in the library as in the post above and did a new test, and found we are both correct. The delay is 1 second and 2 seconds, depending on which side of the router's masquerade the client is on.

I have benchmarked the damn thing enough times now, I tend to think that if you are not seeing a delay in the order of 1500 to 2000ms after the buffers are saturated, you might not be measuring it right.

Quote
If I request the page from a local interface on my router (ethernet), the delays are 1 second (10 to 12 '+').

You are measuring the delay at the sending end.  How do you know the data which was purportedly sent, exited the interface and reached the other end?  My measurements were verified by benchmarking all three points.  The sending end, on the wire in between and at the receiving end.  Wireshark is by far the most revealing.

Masquerading should have nothing to do with it.  I say should, because there is something very odd going on with the session management and I haven't quite worked out all the implications of it.  In a nutshell, the shield appears to not be honouring TCP state transitions.  You touched on it in an earlier post.  I had a poke around with the ServerDrv class.  It looks very much like the shield enters a bogus state, where  a single socket is both ESTABLISHED and LISTENing. 
Refs, ServerDrv::getClientStatus, ServerDrv::getServerStatus, ServerDrv::startServer.

ServerDrv is not documented, so I could be short circuiting something but you also noted that out of the four socket structures the shield is supposed to maintain, it apparently only ever uses one.

Quote
edit: Whoa! Here is a shocker! Somebody just downloaded the waterfal.jpg image from the internet, and the delays were minimal (2 to 3 '+'). And it was fast enough to not timeout on the favicon.ico.

How do you know the data was served?  The throughput would be ~20 times the mean.  The likely hood is, it did not happen as you think.  If it did happen, it is more fuel for the fire.  An interface with throughput varying by so much for no explicable reason, is as good as broken.
 
Quote
Each "!*" pair is a packet.

Do you mean a packet or do you mean a write to the SPI bus?

Your server is down BTW.
Logged

Miramar Beach, Florida
Offline Offline
Faraday Member
**
Karma: 115
Posts: 5380
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Yes, it appears it was down. That was the first fail since I started experimenting with it. The Windows computer is was connected to crashed. It should be up again now. It is a holiday over here and I was visiting my family.

"!*" is a packet or SPI write. I send what I calculate as 7 packets using client.write(), and I see "!*!*!*!*!*!*!*". It may be sent by the wifi shield as one packet. That I cannot guarantee. The "+" is a 100ms delay. That I can guarantee. Any way you look at the math, delay(100) is a 100ms delay. One times that (+) is 1/10th of a second. Ten times that (++++++++++) is a second. Twenty times that (++++++++++++++++++++) is two seconds. I think that works the same on both sides of the Atlantic. I can watch the serial monitor and see how fast the downloads are happening. The timing on all three computers here are showing that timing as correct. However, the internet computers that surprised me downloaded the files fast, noticeably faster than mine. It is not difficult to tell the difference when talking about 20+ seconds difference.

If I start a download with one computer, then try to download with another computer, I get a "connecting" message until the current download is finished, then I get a "connected" message and the download starts. Using the ethernet shield, I get "connecting", then almost immediately "connected" but no download starts on the second connection until the current download is finished. I can see that with the socket status monitors I use. According to them, the ethernet shield does use all 4 sockets, and the wifi shield uses only one.

You seem to be the only other person here besides PaulS and myself that really cares anything about this. Nobody else has responded, so it is difficult to tell how it is actually working on the client end. Check with your wireshark and let me know what you see.

edit: If other users would like to help with this, the ip of the wifi server is http://68.99.58.119. Try the image downloads and watch this thread. I may have to leave today for a while, but I will be here for the next couple hours.

It appears here it may be the web browser, not the masquerade/nat. I tried with Chrome on local interface, and got the 1.2 second delays every delay. I tried with IE on the same computer, and the delays were short (++) about half the time (every other delay). Tried with Firefox remote (WAN) interface, and got the 2 second delays consistently. ??
« Last Edit: November 29, 2013, 07:08:59 am by SurferTim » Logged

Emsworth, UK
Offline Offline
Full Member
***
Karma: 6
Posts: 181
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Yes, it appears it was down. That was the first fail since I started experimenting with it.

It's down again.  Looks like I can crash it on demand.  Sorry about that.

Quote
"!*" is a packet or SPI write. I send what I calculate as 7 packets using client.write(),

It's an SPI write.  A packet is something else.  The distinction is important.

Quote
Any way you look at the math, delay(100) is a 100ms delay.

Yes, I get what delay(100) does.  What you don't appear to be getting is the bus write is decoupled from the network write.  What role is that gert big AT32UC1512 playing in all this?
 
Quote
However, the internet computers that surprised me downloaded the files fast, noticeably faster than mine.

You do not know whether those computers downloaded anything at all.

Quote
It is not difficult to tell the difference when talking about 20+ seconds difference.

So try to explain the variation to me.  What mechanism could cause the throughput to go from an average <20Kbps to over 500Kbps?  The most likely answer is, it doesn't.

Quote
If I start a download with one computer, then try to download with another computer, I get a "connecting" message until the current download is finished, then I get a "connected" message and the download starts.

Yes.  The TCP session handling appears to be borked.

Quote
According to them, the ethernet shield does use all 4 sockets, and the wifi shield uses only one.

Server_Drv.h contains the prototypes for  ServerDrv::getClientStatus(socketIndex) and ServerDrv::getServerStatus(socketIndex), which return values enumerated to TCP Socket states. 
0 = CLOSED, 1 = LISTENING, 4 = ESTABLISHED.

The state transition looks like this
Code:
status: Client, Server
        0       0           //Closed
        0       1           //Listen
        4       1           //borked! 
A TCP Socket can not be ESTABLISHED and LISTENing at the same time.

Calling ServerDrv::startServer on a Socket which is already LISTENing causes new connection attempts to be rejected.  But I can not for the life of me get another socket to start listening.  As far as I can tell, the problem is on the other side of the SPI bus - Beyond my ability to debug or do anything about it.

Quote
You seem to be the only other person here besides PaulS and myself that really cares anything about this.

LOL.  I guess I care that you don't post sarcastic comments alluding to my having made stuff up!

I also care not to encourage people to waste money on a device, which is unlikely to meet their expectations.  The WiFi shield is a candidate for the draw of shame - You know, that draw full of stuff that is never used.   The shield is not entirely useless but reliably serving interactive web pages onto the internet, is currently beyond it. 

Apart from that, call it a professional interest.  Poking around with the WiFi shield has been reminding me of what I take for granted.  Sockets being no more than data structures in software, for instance.

Quote
Nobody else has responded, so it is difficult to tell how it is actually working on the client end.   Check with your wireshark and let me know what you see.

I write my own clients.  The compiler I am using is paid for but there are plenty of free tools, including Processing.  You can download Wireshark for free too.

Logged

Miramar Beach, Florida
Offline Offline
Faraday Member
**
Karma: 115
Posts: 5380
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

It was down. I was playing with it for a few minutes. It is up now.

I think the difference is the browser. I get different delays every time I switch web browsers. I would like to hear from any users about the web browser they use to download the images.
Logged

Miramar Beach, Florida
Offline Offline
Faraday Member
**
Karma: 115
Posts: 5380
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Whoever just downloaded the soccer pic, you had minimal delay. Only the first delay had a 1.5 second delay. All other delays in that download had only one '+'.

The second download had only a one second delay the first delay. Al others were 1/10th second.

edit: And another download that had a 1.5 second first delay (+++++++++++++++), and the rest were 1/5th second (++).
« Last Edit: November 29, 2013, 09:29:36 am by SurferTim » Logged

Pages: 1 ... 3 4 [5] 6 7 ... 9   Go Up
Jump to: