Re: [lwip-users] Why retransmit didn't work in my lwip stack?

[Ashish Anand]

Hi there,

I am also trying to run a TCP server on ARM under eCos and am having major
problems with the SYN/ACK packets.
If you go through my posts on the forum, you might be able to help me out.

Post 1: http://lists.gnu.org/archive/html/lwip-users/2007-02/msg00044.html
Post 2: Today's list (not up yet), titled "SYN/ACK issues... ARM... TCP...
eCos...."

Kindly show me your code if you do not mind, or help me out with the above
posts!
The code for making the webserver given in the LwIP pdf does not work over
eCos for me.

Regards,
Ashish Anand
Research Intern - Dept. of Electrical Engineering
Indian Institute of Technology, Delhi
http://dudafunk.myvnc.com



geckook Xu wrote:
> 
> when lwip receive about 80kb data, lwip will didn't respond to the
> next data frame. ant the client will transmit the frame,but lwip
> didn't respond.
> 
> On 3/1/07, address@hidden <address@hidden>
> wrote:
>> Send lwip-users mailing list submissions to
>>        address@hidden
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>        http://lists.nongnu.org/mailman/listinfo/lwip-users
>> or, via email, send a message with subject or body 'help' to
>>        address@hidden
>>
>> You can reach the person managing the list at
>>        address@hidden
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of lwip-users digest..."
>>
>>
>> Today's Topics:
>>
>>   1. Re: Why does sys_sem_wait_timeout exist? (Atte Kojo)
>>   2. Re: Why does sys_sem_wait_timeout exist? (Kieran Mansley)
>>   3. Re: Why does sys_sem_wait_timeout exist? (Atte Kojo)
>>   4. Re: Why does sys_sem_wait_timeout exist? (Kieran Mansley)
>>   5. Re: [lwip-devel] I only can create 16 concurrent  connections,
>>      What should I do? (geckook Xu)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Wed, 28 Feb 2007 08:26:19 +0200
>> From: Atte Kojo <address@hidden>
>> Subject: Re: [lwip-users] Why does sys_sem_wait_timeout exist?
>> To: Mailing list for lwIP users <address@hidden>
>> Message-ID: <address@hidden>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> Jonathan Larmour wrote:
>> > Packet-oriented netbufs can be used more efficiently than streams, and
>> > you can't do things like netbuf_ref() etc. with streams.
>> I'm afraid that I don't quite understand this. Could you elaborate a bit
>> more?
>>
>> As far as I understand, when running in flat memory "zero-copy" is more
>> of an illusion than anything else. Right now writes/sends on UDP sockets
>> with socket API are already blocking and don't copy any data between
>> pbufs (uses netbuf_ref i.e. PBUF_REF). TCP writes could very easily be
>> made "zero-copy" also with a non-standard option for send (like
>> MSG_DONTCOPY, which would then use netbuf_ref/PBUF_REF under the covers).
>>
>> In any case not copying data for performance reasons is kind of a moot
>> point as the data must be gone through at least once when calculating
>> checksums. Doing a copy-on-checksum takes almost negligible performance
>> hit (depending on memory allocator implementation) so only real case for
>> not copying data at all is for very memory-constrained systems where the
>> user wants to avoid copying data from external ROM to RAM. And, as I
>> said earlier, this can be handled very easily.
>>
>> PS. The main reason I'm so strongly advocating this is that I don't like
>> having a nonstandard API where a standard one would do. Using a socket
>> API that behaves just like its real counterpart is a lot easier for new
>> users (and us old ones also). Plus the netconn-API lacks select() which
>> makes single-thread servers a gazillion times easier to implement.
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Wed, 28 Feb 2007 09:19:47 +0000
>> From: Kieran Mansley <address@hidden>
>> Subject: Re: [lwip-users] Why does sys_sem_wait_timeout exist?
>> To: Mailing list for lwIP users <address@hidden>
>> Message-ID: <address@hidden>
>> Content-Type: text/plain
>>
>> On Wed, 2007-02-28 at 08:26 +0200, Atte Kojo wrote:
>> > As far as I understand, when running in flat memory "zero-copy" is more
>> > of an illusion than anything else. Right now writes/sends on UDP
>> sockets
>> > with socket API are already blocking and don't copy any data between
>> > pbufs (uses netbuf_ref i.e. PBUF_REF). TCP writes could very easily be
>> > made "zero-copy" also with a non-standard option for send (like
>> > MSG_DONTCOPY, which would then use netbuf_ref/PBUF_REF under the
>> covers).
>>
>> This is perhaps a bit of a tangent to your point but implementing zero-
>> copy writes for TCP through the sockets API is very difficult unless the
>> application can guarantee that the data are static and it will never
>> modify the buffers it passes in.  The sockets API can't make this sort
>> of guarantee (and so it would have to be a modified API as you suggest)
>> and the number of applications that *can* make that sort of guarantee
>> without using vast quantities of memory is very small.  As such I don't
>> think this specific change would be the best use of our time.
>> Particularly, as you point out, that for a stack such as lwIP doing the
>> copy during the checksum is not a big deal, and we're not looking for
>> stella performance as our main goal.
>>
>> > PS. The main reason I'm so strongly advocating this is that I don't
>> like
>> > having a nonstandard API where a standard one would do. Using a socket
>> > API that behaves just like its real counterpart is a lot easier for new
>> > users (and us old ones also). Plus the netconn-API lacks select() which
>> > makes single-thread servers a gazillion times easier to implement.
>>
>> I agree with you that the sockets API as it standards is incomplete and
>> non-standard, but in many cases has proved to be "good enough" for many
>> people.  It's pretty stable, but I'm pretty sure it's not bug-free.  It
>> would be nice to be able to throw it away and start again with something
>> built directly on the raw API (I did this for my own project when first
>> working with lwIP, but it was so specialised as to be of no use to
>> anyone else) as we could undoubtedly do better, but we'd lose some of
>> the current stability and we'd need more active developers than we
>> currently have.
>>
>> I see lwIP as pretty much stable and mature, and so I'm fairly
>> conservative about major code changes or rewrites.  The sort of thing
>> you're proposing would be great for a version 2, but I don't anticipate
>> there being a version 2 any time soon.
>>
>> Kieran
>>
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Wed, 28 Feb 2007 11:59:04 +0200
>> From: Atte Kojo <address@hidden>
>> Subject: Re: [lwip-users] Why does sys_sem_wait_timeout exist?
>> To: Mailing list for lwIP users <address@hidden>
>> Message-ID: <address@hidden>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> Kieran Mansley wrote:
>> > On Wed, 2007-02-28 at 08:26 +0200, Atte Kojo wrote:
>> >
>> >> As far as I understand, when running in flat memory "zero-copy" is
>> more
>> >> of an illusion than anything else. Right now writes/sends on UDP
>> sockets
>> >> with socket API are already blocking and don't copy any data between
>> >> pbufs (uses netbuf_ref i.e. PBUF_REF). TCP writes could very easily be
>> >> made "zero-copy" also with a non-standard option for send (like
>> >> MSG_DONTCOPY, which would then use netbuf_ref/PBUF_REF under the
>> covers).
>> >>
>> >
>> > This is perhaps a bit of a tangent to your point but implementing zero-
>> > copy writes for TCP through the sockets API is very difficult unless
>> the
>> > application can guarantee that the data are static and it will never
>> > modify the buffers it passes in.  The sockets API can't make this sort
>> > of guarantee (and so it would have to be a modified API as you suggest)
>> > and the number of applications that *can* make that sort of guarantee
>> > without using vast quantities of memory is very small.  As such I don't
>> > think this specific change would be the best use of our time.
>> > Particularly, as you point out, that for a stack such as lwIP doing the
>> > copy during the checksum is not a big deal, and we're not looking for
>> > stella performance as our main goal.
>> >
>> Yes, I seem to be drifting more and more off-topic in this thread ;-). I
>> didn't mean to say that using zero-copy and TCP would be a very good
>> idea. I was just pointing out that everything that can be done using
>> netbufs and netconn API can easily be done using socket API, with minor
>> nonstandard changes (i.e. some new flags) to the API.
>> >> PS. The main reason I'm so strongly advocating this is that I don't
>> like
>> >> having a nonstandard API where a standard one would do. Using a socket
>> >> API that behaves just like its real counterpart is a lot easier for
>> new
>> >> users (and us old ones also). Plus the netconn-API lacks select()
>> which
>> >> makes single-thread servers a gazillion times easier to implement.
>> >>
>> >
>> > I agree with you that the sockets API as it standards is incomplete and
>> > non-standard, but in many cases has proved to be "good enough" for many
>> > people.  It's pretty stable, but I'm pretty sure it's not bug-free.  It
>> > would be nice to be able to throw it away and start again with
>> something
>> > built directly on the raw API (I did this for my own project when first
>> > working with lwIP, but it was so specialised as to be of no use to
>> > anyone else) as we could undoubtedly do better, but we'd lose some of
>> > the current stability and we'd need more active developers than we
>> > currently have.
>> >
>> Sorry, I didn't probably express myself as clearly as I wanted. I didn't
>> mean to berate the socket API in any. We're using it in a production
>> system and it works very well. My main point was that I don't really see
>> the reason why netconn API and sockets API should continue to be
>> developed in parallel since both implement essentially the same
>> functionality. My opinion is that the two could be merged so that
>> sockets API would replace the netconn API. And raw API would continue to
>> be developed as before.
>> > I see lwIP as pretty much stable and mature, and so I'm fairly
>> > conservative about major code changes or rewrites.  The sort of thing
>> > you're proposing would be great for a version 2, but I don't anticipate
>> > there being a version 2 any time soon.
>> >
>> Our version of lwIP has been completed for quite some time now and is in
>> a maintenance/bugfix phase for the current product line where it is used
>> so I wouldn't want any major changes either :-). And unfortunately due
>> to our nonstandard hardware, our version differs quite a lot from the
>> vanilla version.
>>
>> But, (a BIG) if we're starting development of a new product utilizing
>> lwIP and a decent microcontroller, I'd be more than happy to help in
>> developing a new version of lwIP. I think that overall it is a very nice
>> system, but could use a bit of cleanup here and there.
>>
>> - Atte
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Wed, 28 Feb 2007 10:09:41 +0000
>> From: Kieran Mansley <address@hidden>
>> Subject: Re: [lwip-users] Why does sys_sem_wait_timeout exist?
>> To: Mailing list for lwIP users <address@hidden>
>> Message-ID: <address@hidden>
>> Content-Type: text/plain
>>
>> On Wed, 2007-02-28 at 11:59 +0200, Atte Kojo wrote:
>> >  I think that overall it is a very nice
>> > system, but could use a bit of cleanup here and there.
>>
>> That should be our project motto. :)
>>
>> Kieran
>>
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Wed, 28 Feb 2007 23:23:45 +0800
>> From: "geckook Xu" <address@hidden>
>> Subject: [lwip-users] Re: [lwip-devel] I only can create 16 concurrent
>>        connections, What should I do?
>> To: address@hidden
>> Message-ID:
>>        <address@hidden>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> I use sockets.c api.
>>
>> When I create the 17th concurrent connection,The server program block
>> at function lwip_read();
>>
>> Yes,I enable the debug and print out the states of memory.
>> But no err found.
>>
>>
>> > > I increase the pcb num,but it does not work.
>> >
>> > [NB. I've replied to lwip-users rather than lwip-devel - it is more
>> > appropriate for this to be discussed there]
>> >
>> > Can you find where it is blocking in lwIP?  This might give you a clue
>> > about which resource there is insufficient of to satisfy the 17th
>> > connection.
>> >
>> > I'm surprised that there are no errors output in this case.
>>
>> >Also, which lwIP API are you using?
>>
>> >Kieran
>> -------------- next part --------------
>> /*
>>  * Copyright (c) 2001, 2002 Swedish Institute of Computer Science.
>>  * All rights reserved.
>>  *
>>  * Redistribution and use in source and binary forms, with or without
>> modification,
>>  * are permitted provided that the following conditions are met:
>>  *
>>  * 1. Redistributions of source code must retain the above copyright
>> notice,
>>  *    this list of conditions and the following disclaimer.
>>  * 2. Redistributions in binary form must reproduce the above copyright
>> notice,
>>  *    this list of conditions and the following disclaimer in the
>> documentation
>>  *    and/or other materials provided with the distribution.
>>  * 3. The name of the author may not be used to endorse or promote
>> products
>>  *    derived from this software without specific prior written
>> permission.
>>  *
>>  * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
>> IMPLIED
>>  * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
>>  * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
>> IN NO EVENT
>>  * SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
>> SPECIAL,
>>  * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
>> PROCUREMENT
>>  * OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
>> BUSINESS
>>  * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
>> IN
>>  * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
>> OTHERWISE) ARISING
>>  * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
>> POSSIBILITY
>>  * OF SUCH DAMAGE.
>>  *
>>  * This file is part of the lwIP TCP/IP stack.
>>  *
>>  * Author: Adam Dunkels <address@hidden>
>>  *
>>  */
>>
>> #ifndef __LWIPOPTS_H__
>> #define __LWIPOPTS_H__
>>
>> #if 1
>> #define LWIP_DEBUG
>> #define DBG_MIN_LEVEL   0
>> #define DBG_TYPES_ON    (DBG_ON | DBG_TRACE | DBG_STATE | DBG_FRESH |
>> DBG_HALT)
>> #if 0
>> #define TCP_DEBUG       DBG_OFF
>> #define TCP_QLEN_DEBUG  DBG_OFF
>> #define TCP_OUTPUT_DEBUG        DBG_ON
>> #define TCP_RTO_DEBUG   DBG_ON
>> #define TCP_FR_DEBUG    DBG_ON
>> #define TCP_CWND_DEBUG                  DBG_ON
>> #define TCP_WND_DEBUG                   DBG_ON
>> #define TCP_RST_DEBUG                   DBG_ON
>> #endif
>> #if 1
>> #define LINK_STATS  1
>> #define IP_STATS    1
>> #define IPFRAG_STATS    1
>> #define ICMP_STATS  1
>> #define UDP_STATS   1
>> #define TCP_STATS   1
>> #define MEM_STATS   1
>> #define MEMP_STATS  1
>> #define PBUF_STATS  1
>> #define SYS_STATS   1
>> #define RAW_STATS   1
>> #define LWIP_STATS_DISPLAY  1
>> #endif
>> #define MEM_DEBUG       DBG_ON
>> #define MEMP_DEBUG      DBG_ON
>> #if 0
>> #define TCP_INPUT_DEBUG DBG_ON
>> #define RAW_DEBUG       DBG_OFF
>> #define PBUF_DEBUG      DBG_OFF
>> #endif
>> #endif
>>
>> //efine SO_REUSE        1
>> #define NO_SYS                  0
>> #define LWIP_CALLBACK_API       1
>> #define LWIP_DHCP               0
>> #define SYS_LIGHTWEIGHT_PROT            1
>>
>> /* #define TCP_TMR_INTERVAL     250 */
>> #define TCP_TMR_INTERVAL        250
>>
>> /* ---------- Memory options ---------- */
>> /* MEM_ALIGNMENT: should be set to the alignment of the CPU for which
>>   lwIP is compiled. 4 byte alignment -> define MEM_ALIGNMENT to 4, 2
>>   byte alignment -> define MEM_ALIGNMENT to 2. */
>> /* tried 4 byte alignment, but that seems to cause problems with pbuf
>>  * routines */
>> #define MEM_ALIGNMENT           4
>>
>> /* MEM_SIZE: the size of the heap memory. If the application will send
>> a lot of data that needs to be copied, this should be set high. */
>> #define MEM_SIZE                1024*110
>>
>> /* The following four are used only with the sequential API and can be
>>   set to 0 if the application only will use the raw API. */
>> /* MEMP_NUM_NETBUF: the number of struct netbufs. */
>> #define MEMP_NUM_NETBUF         2*10
>> /* MEMP_NUM_NETCONN: the number of struct netconns. */
>> #define MEMP_NUM_NETCONN        4+14//??????15??????????
>> #define MEMP_NUM_TCP_PCB                5*10
>>
>> /* MEMP_NUM_APIMSG: the number of struct api_msg, used for
>>   communication between the TCP/IP stack and the sequential
>>   programs. */
>> #define MEMP_NUM_API_MSG        16
>> /* MEMP_NUM_TCPIPMSG: the number of struct tcpip_msg, which is used
>>   for sequential API communication and incoming packets. Used in
>>   src/api/tcpip.c. */
>> #define MEMP_NUM_TCPIP_MSG      16*10
>>
>> #define MEMP_NUM_SYS_TIMEOUT            3+2
>>
>> #define PBUF_POOL_SIZE          16*32
>> #define PBUF_POOL_BUFSIZE       128
>> #define PBUF_LINK_HLEN          14
>>
>> #define TCP_MSS                 1460
>>
>> /* TCP_SND_BUF should be less than or equal to MEMP_NUM_TCP_SEG *
>>  * TCP_MSS otherwise the system will not be able to allocate enough
>>  * tcp_segs to transmit all the data and will return ERR_MEM when
>>  * attempting to transmit large amounts of data.  You want to guarantee
>>  * that there are more tcp_segs than there is memory.  Each segment
>>  * is equal to TCP_MSS.
>>  */
>> #define MEMP_NUM_TCP_SEG        255
>>
>> #define TCP_WND                 2048
>> #define TCP_SND_BUF             (MEMP_NUM_TCP_SEG-1) * TCP_MSS
>> #define LWIP_MAX_QS 20*10              /* Max. LwIP queues */
>> #endif /* __LWIPOPTS_H__ */
>>
>> ------------------------------
>>
>> _______________________________________________
>> lwip-users mailing list
>> address@hidden
>> http://lists.nongnu.org/mailman/listinfo/lwip-users
>>
>> End of lwip-users Digest, Vol 42, Issue 36
>> ******************************************
>>
> 
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Why-retransmit-didn%27t-work-in-my-lwip-stack--tf3332321.html#a9306536
Sent from the lwip-users mailing list archive at Nabble.com.