lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] Multi-Threaded netconn API TCP application


From: Sylvain Rochet
Subject: Re: [lwip-users] Multi-Threaded netconn API TCP application
Date: Sun, 20 Sep 2015 20:52:25 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Hi Pirvu,


On Sun, Sep 20, 2015 at 02:05:38PM +0300, Pîrvu Mihai wrote:
> Hello guys, I'm sorry if this was posted before, but i couldn't find an
> answer, so I'm gonna post here in search of one.
> 
> I want to create a simple multi-threaded TCP server, that handled each new
> connection on a separate thread. The listener thread will listen on the
> "main" thread, and every connection will create a new thread, that will
> communicate with the session created.
> 
> The code I wrote is here: http://pastebin.com/zUuTtfL0
> 
> I have dug a little into the lwip API to see how netconn_accept works and I
> saw that it blocks until the "not_empty" semaphore frm the "acceptbox"
> mailbox has something in it.
> 
> Now, every time this happens, I create a new thread and the session
> creation is done there, and I block the main thread using the "semaphore"
> variable, so a new connection doesn't happen while I still proces the old
> one.
> 
> Now, the problem is pretty much this:
> - I connect the first client, it works just fine
> - When ANY second client tries to join, it automatically gets disconnected
> and the server's console prints: Disconnected: 1, so netconn_recv doesn't
> return ERR_OK.

Could you share your MEMP_NUM_TCP_PCB, MEMP_NUM_NETCONN, MEMP_NUM_NETBUF 
values ?  It looks like you don't have enough of them.


> So my question is:
> - How can I create this multi-threaded enviroment so each client is
> processed in a different thread?
> - Also, what am I doing wrong in my current setup ?
> 
> PS: The application runs on Linux atm, using lwip 1.4.0 (last stable one),
> the unix port from contrib directory and the clients connect using netcat
> <ip> <port>.

The only lwIP constraint on netconn control block is that netconn 
functions are only thread safe against the core, they are not 
reentrant, so you cannot share the control block between thread without 
locking.

Why are you not processing the new TCP session in the current thread and 
having your create_thread() just waiting on accept for a new incoming 
session ? This will solve any issue about control block locking between 
threads.


Sylvain

Attachment: signature.asc
Description: Digital signature


reply via email to

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