lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-users] AW: SOLVED - Failed to send large files ( > 64 kb ) over TC


From: Richner Simon
Subject: [lwip-users] AW: SOLVED - Failed to send large files ( > 64 kb ) over TCP
Date: Wed, 8 Sep 2010 09:22:26 +0200

Hi Bill,
 
Thanks for the NIOS II TSE example, it realy helped me a lot getting started.
 
My problem was purely application based...
 
There is no size limitation, neighter in the stack, nor in the httpserver. The problem was really the client browser, who sent this RST flag, causing the lwip-stack to trash the active tcpsndqueue (which is a reasonable thing to do in this case).
 
The reason why the client browser (Internet-Explorer & Firefox) sends this RST flag is that the httpserver in the NIOS II TSE example isn't a real server, but just contains a hard-coded http-header:
 
HTTP/1.0 200 OK
Server: lwIP/pre-0.6 (http://www.sics.se/~adam/lwip/)
Content-type: image/gif
 
I'm not too familiar with the HTTP-specifications, but the problem seems to be, that if a message is larger than the MSS, specified by the client, the server is expected to set the Content-Length Option. This makes it a little tricky, to exchange hard-coded pictures or data in the fsdata.c file as the http header has to match the size of the code. But if somebody wants to use the NIOS II TSE example as a real http server, he would have to generate the http header dynamically anyways. For my test-picture I'm happy with this header hard-coded in fsdata.c:
 
HTTP/1.0 200 OK
Server: http://my-server.ch
Content-type: image/gif
Content-Length: 288312
 
PS: The moment when the client sends its RST flag seems to be pretty random, it can be after the first segment or after the hole message has already been sent. So I've no clue, why in my case it always happend when the file size got larger than 64kb :)
 
Cheers
Simon
 
 


Von: address@hidden [mailto:address@hidden Im Auftrag von Bill Auerbach
Gesendet: Dienstag, 7. September 2010 18:59
An: 'Mailing list for lwIP users'
Betreff: RE: [lwip-users] Failed to send large files ( > 65 kB ) over TCP

Simon,

 

As this example is based on the the contrib folder httpserver_raw in unmodified source, I am surprised this hasn’t come up before.  There was a problem once that the file system would truncate files to 64k when sizeof int was 2, but on the NIOS II int is 32-bits and there is no 64k file size limit.  Perhaps this demo has always had this limitation – I don’t know.

 

I am readying for a trade show and will look at this more when I get a chance (which is next week at the soonest).

 

Bill  ß the one who posted the NIOS II TSE example.

 

From: address@hidden [mailto:address@hidden On Behalf Of Richner Simon
Sent: Monday, September 06, 2010 11:18 AM
To: Mailing list for lwIP users
Subject: [lwip-users] Failed to send large files ( > 65 kB ) over TCP

 

Hi,

 

I'm using LwIP 1.3.2 without OS. My driver is based on the Altera TSE example, posted on the LwIP Wiki driver page. This example includes a minimal HTTP server which I use as basis and which works without problems.

 

Then I replaced the gif-image, located on the server example, by a larger image (130kB). As far as I understand, the send_data function in httpd.c should handle this situation, splitting the pictures in several segments, matching the actual free size of the tcp_sendbuf. After sending part of the image, the http_sent function should then continue to send the rest of the image.

 

As I already mentioned, with images, having less than 65'536 bytes, this works as I would expect. With larger images, I get a Connection RESET merssage from the tcp_process function in tcp_in.c rigth after the first segment was sent. This will immediately free all pbufs, belonging to the pcb_sndqueue - including those that have not been sent yet.

 

My questions:

 

- Is there a size limit in tcp_write, other than the one, given by tcp_sndbuf(pcb)?  If yes, can I change it, what are the consequences?

- Is it normal to get reset requests from the client, when using the Altera TSE example driver? What situation would cause a client to send a reset request?

 

Best Regards

Simon

 

 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]