tux-droid-user

[tuxdroid-user] Small issue with tcp/ip when disconnecting the socket

[David B. <da...@ja...>]

Hi neimad,

You removed a usleep in send_daemon_disconnected() and asked me why it was  
there.

     tcp_server_send_raw(data);
     usleep(?);
     close(tcp_server_handle);

I had no idea but I now found that sometimes the client doesn't get the  
message so the daemon quits but the client is still hooked on the socket.
Does it also relates to the fact that sockets are now non-blocking?

Any idea on what to do here?

Thanks,
David

Re: [tuxdroid-user] Small issue with tcp/ip when disconnecting the socket

[David B. <da...@ja...>]

False alarm, it seems it's a bug in tuxgi which still tries to get the RF  
status even after it's disconnected. Sorry for the trouble :-/

But looking into this, I came up with a question about this:
  if ((send(tcp_clients_handle[i], data, sizeof(tcp_frame_t), 0)) == 0)
             tcp_remove_client(i);

Rémi got this in the past if the client was exited without telling to the  
daemon, 'send' would return 0.
Looking at the man page, I can't find how send can return 0, at least now  
in non blocking mode either it adds the data or it returns -1 as an error.  
But in blocking mode, 0 would mean that 0 bytes have been successfully  
sent. Any clarification about this?
I guess that we can change the '== 0' into '<= 0' or better '< 0' if we're  
sure 0 can't happen anymore in non-blocking mode.

Cheers,
David

Re: [tuxdroid-user] Small issue with tcp/ip when disconnecting the socket

[neimad <ror...@gm...>]

"David Bourgeois" <da...@ja...> writes:
> But looking into this, I came up with a question about this:
>  if ((send(tcp_clients_handle[i], data, sizeof(tcp_frame_t), 0)) =3D=3D 0)
>             tcp_remove_client(i);
>
> R=C3=A9mi got this in the past if the client was exited without telling to
> the  daemon, 'send' would return 0.
> Looking at the man page, I can't find how send can return 0, at least
> now  in non blocking mode either it adds the data or it returns -1 as
> an error.  But in blocking mode, 0 would mean that 0 bytes have been
> successfully  sent. Any clarification about this?
> I guess that we can change the '=3D=3D 0' into '<=3D 0' or better '< 0' if
> we're  sure 0 can't happen anymore in non-blocking mode.

Unless I'm mistaken, in the current code the sockets are *blocking*.
If send() returns < 0, we can assume the connection to the client has
been closed, yes.

	Damien