lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] Detecting remote close when using netconn API


From: Krzysztof Wesołowski
Subject: Re: [lwip-users] Detecting remote close when using netconn API
Date: Thu, 12 Apr 2012 20:46:43 +0200

Can I make such non blocking read with already established connection?

Regards,
Krzysztof Wesolowski,



On Thu, Apr 12, 2012 at 2:03 PM,  <address@hidden> wrote:
> Send lwip-users mailing list submissions to
>       address@hidden
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://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. Detecting remote close when using netconn API
>      (Krzysztof Weso?owski)
>   2. Re: Detecting remote close when using netconn API (Kieran Mansley)
>   3. tcp_sndbuf return 0 when sending file (vincent cui)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 12 Apr 2012 00:44:48 +0200
> From: Krzysztof Weso?owski <address@hidden>
> To: address@hidden
> Subject: [lwip-users] Detecting remote close when using netconn API
> Message-ID:
>        <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-2
>
> Hi,
>
> I am using netcon api in simple application. Device is a server
> processing connections in loop, PC is a client. After PC establishes
> connection we go into simple loop:
>
>    while (err == ERR_OK) {
>        if (streaming_enabled()) {
>            err = netconn_write(pc,sbuf, 1152, NETCONN_COPY);
>        }
>        vTaskDelay(1);
>    }
>
> where pc is struct netconn *.
>
> However if streaming is disabled, there is now way we can detect that
> PC sent FIN and closed connection - so subsequent connection to same
> port to server causes RST (we are still in inner loop so we cannot
> accept next connection).
>
> What can i do to detect that PC closed connection? I do not mean
> Ethernet layer error and other "hard do diagnose in few miliseconds"
> problems, rather typical situation with connection closed by PC.
>
> Regards,
> Krzysztof Weso?owski,
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 12 Apr 2012 09:44:45 +0100
> From: Kieran Mansley <address@hidden>
> To: Mailing list for lwIP users <address@hidden>
> Subject: Re: [lwip-users] Detecting remote close when using netconn
>        API
> Message-ID:
>        <address@hidden>
> Content-Type: text/plain; charset="UTF-8"
>
> On Thu, 2012-04-12 at 00:44 +0200, Krzysztof Weso?owski wrote:
>> What can i do to detect that PC closed connection?
>
> The simplest way would be to do a non-blocking read from the connection.
> If the PC has closed it in that direction, you will get an error.
>
> Kieran
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 12 Apr 2012 07:09:48 +0000
> From: vincent cui <address@hidden>
> To: Mailing list for lwIP users <address@hidden>
> Subject: [lwip-users] tcp_sndbuf return 0 when sending file
> Message-ID:
>        <address@hidden>
> Content-Type: text/plain; charset="us-ascii"
>
> All
>
> I develop a FTP server with lwIP 1.3.2 in Cortex M3 platform, when I use 
> FlashFXP to get file from the server, the tcp_sndbuf always return 0 after 
> work a while .
> I capture it with wireshark, the file is attached file. The server ip: 
> 192.168.1.51. it seems that transfer error and need retransmission.
>
> [Untitled.png]
>
> My sendcode in server is below:
>
> static void send_data(struct tcp_pcb *pcb, struct ftpd_datastate *fsd)
> {
>    err_t err;
>    u16_t len;
>    int i;
>    if (sfifo_used(&fsd->fifo) > 0)
>         {
>        if (tcp_sndbuf(pcb) < sfifo_used(&fsd->fifo))
>                   {
>            len = tcp_sndbuf(pcb);   -> the len is set 0 after work a while.
>        }
>                   else
>                   {
>            len = (u16_t)sfifo_used(&fsd->fifo);
>        }
>
>        i = fsd->fifo.readpos;
>        if ((i + len) > fsd->fifo.size)
>                   {
>            err = tcp_write(pcb, fsd->fifo.buffer + i, (u16_t)(fsd->fifo.size 
> - i), 1);
>            if (err != ERR_OK)
>                            {
>                return;
>            }
>            len -= fsd->fifo.size - i;
>            fsd->fifo.readpos = 0;
>            i = 0;
>        }
>                   err = tcp_write(pcb, fsd->fifo.buffer + i, len, 1);
>        if (err != ERR_OK)
>                   {
>             return;
>        }
>         fsd->fifo.readpos += len;
>    }
> }
>
> Who know how to solve ?
> Vincent Cui
> Software Engineer Leader
> Mobile: +8613255150315
> Tel: +86 21 34612525x6104
> Fax: +86 21 34619770
> E-Mail: address@hidden<mailto:address@hidden>
> Shanghai EnLogic Electric Technology Co., Ltd.
> Address: 1104-1106, Building A, No.391, Guiping Road, Xuhui District, 
> Shanghai, 200233
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> <http://lists.nongnu.org/archive/html/lwip-users/attachments/20120412/fb6e52a1/attachment.html>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: image001.png
> Type: image/png
> Size: 27828 bytes
> Desc: image001.png
> URL: 
> <http://lists.nongnu.org/archive/html/lwip-users/attachments/20120412/fb6e52a1/attachment.png>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: sendfileerror.pcap
> Type: application/octet-stream
> Size: 1348287 bytes
> Desc: sendfileerror.pcap
> URL: 
> <http://lists.nongnu.org/archive/html/lwip-users/attachments/20120412/fb6e52a1/attachment.obj>
>
> ------------------------------
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
> End of lwip-users Digest, Vol 104, Issue 6
> ******************************************



reply via email to

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