I tried using the SO_SNDTIMEO. Here is what I am seeing.
1. i create a socket using lwip_socket(AF_INET, SOCK_STREAM, 0) and then
connect using lwip_connect()
2. set the SO_SNDTIME0 to 1s using lwip_setsockopt(socket, SOL_SOCKET,
SO_SNDTIMEO, &timeout_int, sizeof(timeout_int))
3. then start sending data as follows
while(err > 0) {
err = lwip_write(socket, buffer, size);
}
I see that I hit the timeout condition in the 2nd to last transfer
lwip_send(0, data=0x20A72D78, size=86264, flags=0x0) <--- this is the
packet that times out
...
*so_sndtimeo <-- added these printouts to check the condition I am hitting*
*partial write*
lwip_send(0) err=0 written=67348
lwip_send(0, data=0x20A8348C, size=86264, flags=0x0) <--- the last packet
that causes the assert
panic: already writing or closing <--- we hit this in do_write() (
api_msg.c:1360)
Some questions;
1. Does that mean I cannot call lwip_write() after timing out on a previous
call to lwip_write()?
2. Can I use the fact that the size returned by lwip_write() < total buffer
size as an indication that our transfer timed out?
Thanks,
Alhad
On Mon, Oct 12, 2015 at 1:16 PM, Joel Cunningham <[email protected]>
wrote:
> It's a great trick, hopefully others can leverage it as well :)
>
> I'm not sure what I'd do without it. Having select() and non-blocking
> sockets operate as the blocking construct of a server's event loop is
> essential for managing multiple connections in a high performance manner.
>
> Joel
>
> On Oct 12, 2015, at 02:19 PM, Sylvain Rochet <[email protected]>
> wrote:
>
> Hi Joel,
>
> On Mon, Oct 12, 2015 at 07:10:39PM +0000, Joel Cunningham wrote:
>
> You can use SO_SNDTIMEOUT, which should work on LwIP 1.4.1. I have used it
> in my port with LwIP 1.4.1, so possibly there's a problem with your port?
>
>
> I've also written applications that used non-blocking sockets and
>
> select to achieve a similar behavior of having blocking I/O that can
>
> be canceled. The trick here is adding a second socket to the read FD
>
> set in select and then set select to block until your write or read is
>
> ready. This second socket is bound to the loopback address. When you
>
> want to cancel the blocking select from another thread, simply send a
>
> datagram to the additional socket, which will return the select call.
>
> Then you can detect that a cancel/wakeup happened because the second
>
> socket is marked as ready.
>
>
> I really like this trick. It remembers myself of the well known wake up
> pipe I explained here[1], but using the loopback to do so in lwIP is
> very very clever :-)
>
> Sylvain
>
> [1] http://lists.gnu.org/archive/html/lwip-devel/2015-09/msg00028.html
> _______________________________________________
> lwip-users mailing list
> [email protected]
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
>
> _______________________________________________
> lwip-users mailing list
> [email protected]
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users
