lwip-users
[Top][All Lists]
Advanced

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

[lwip-users] Re: [lwip] lwip-cvs-20011210 problems


From: Adam Dunkels
Subject: [lwip-users] Re: [lwip] lwip-cvs-20011210 problems
Date: Wed, 08 Jan 2003 22:20:20 -0000

Hi!

On Monday 10 December 2001 13:19, you wrote:
> 1. the timer are running very fast
> tcp_slowtmr(void) should be 500 ms - but in my system it's about 300 ms.
> I havn't a real good idea for that. The only things I found are in the
> new sys_arch_mbox_fetch() and sys_arch_sem_wait() functions:
> These functions must return at least "1", even if they return immediately
> because of waiting messages/semaphores; this may result in a wrong time
> delay - or I am wrong?

You are right that the "1" return value will cause a certain drift, but 
hardly not enough to explain the 200 ms error that you see (it would require 
that the semaphore was signalled or a message was posted to the mailbox 200 
times in 500 ms). Have you been using the unix/sys_arch.c from the earlier 
CVS version? I fixed a bug which caused weird timers in the unix sys_arch 
just yesterday. 

> 2. repeatedly call of sys_sem_signal()
> After setting up my tcp-echo application and getting an incoming call,
> sys_sem_signal() will be called repeatedly from within tcp_slowtmr(),
> ->poll() without subsequent sys_arch_sem_wait() calls!?

This particular problem was because I hand't written all the code that wa 
really needed. The problem is because netconn_write() blocks in 
sys_sem_wait() if there wasn't enough memory to send the data. The ->poll() 
(poll_tcp() in api_msg.c) signals the semaphore at regular intervals, which 
causes netconn_write() to try again.

> The application works with the sequential api! All tcp data is received
> and transmitted very well. After disconnection (from remote side) the
> PCB stays in CLOSE_WAIT forever.

It might be a stupid question, but do you close the connection at the lwIP 
side? The CLOSE-WAIT state is entered when the remote side has closed the 
connection, but the local application hasn't. 

If you have closed the connection, the problem most likely is that there 
wasn't enough memory to fulfill the close() request, and for some reason 
netconn_close() didn't try again as it should.

> Adam: is your sequential api supported in the futere in lwip 0.5 and up?

Yes.

-- 
Adam Dunkels <address@hidden>
http://www.sics.se/~adam
[This message was sent through the lwip discussion list.]




reply via email to

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