×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

SkySafari Support for INDI

  • Posts: 151
  • Thank you received: 27
Hi!
sorry for bringing up an old topic - but I wrote a LX200 client (that works with KStars, CdC and so on), and I encounter the same problem. When connecting via SkySafari 6 on an android device, connection is established, :GR# is received, a reply is being sent (i use standard C++ and the classical socket mechanism). After that send, the socket goes into an "Bad Address" state and further requests are being ignored. Could that be the problem? And does anyone have an idea how this can be solved? And why does it work with anything else?

BTW, it also works with QTCPServer sockets, which is even more mysterious to me ...

yours
wolfgang
Last edit: 5 years 5 months ago by Wolfgang Birkfellner.
5 years 5 months ago #30842

Please Log in or Create an account to join the conversation.

  • Posts: 151
  • Thank you received: 27
Hi! I found the problem. Sky Safari closes the socket after each write and tries to reconnect. If you don't take care of this on the other side, the socket is dead for further reads. This is in my opinion a bug in SkySafari - or they tried to "flush" the socket with the close command. a workaround is to set the server socket to reuse the port (SO_REUSEADDR) and to set it to immediate shutdown (using SO_LINGER with 0s grace period). If the server closes the receiving socket using "shutdown" and "close", and starts accepting incoming connections immediately after each "write" to SkySafari, it works somehow ...
yours
wolfi
The following user(s) said Thank You: Jasem Mutlaq
5 years 4 months ago #31043

Please Log in or Create an account to join the conversation.

I wonder if this affects the INDI SkyWatcher bridge driver somehow as well.
5 years 4 months ago #31044

Please Log in or Create an account to join the conversation.

  • Posts: 151
  • Thank you received: 27
hi!
this i cannot say - however, look at the traffic:
SSafari (192.168.4.12) sends a request (SYN) and is accepted by the server (192.168.4.1)
SSafari sends an LX command (:GR#) in this case
Server responds
SSafari ACKnowledges and does a FIN signal
the remainder is the result of my reaction as i shutdown socket (that is the RST)
SSafari sends another SYN and is, in this case accepted again.

If I don't do this, SSafari sends a FIN and a millisecond later a SYN request comes in. in this case, no RST takes place. I do not claim to be the worlds greatest programmer or expert on TCP/IP, but to this looks as if they kill the client on their side after each write. QTCPServer sockets "tolerate" this, I do not know why yet. BSD standard sockets react on that FIN signal ...
yours
wolfi
5 years 4 months ago #31045
Attachments:

Please Log in or Create an account to join the conversation.

This is using SkySafari 5 or 6?
5 years 4 months ago #31046

Please Log in or Create an account to join the conversation.

  • Posts: 151
  • Thank you received: 27
SkySafari 6 pro
Last edit: 5 years 4 months ago by Wolfgang Birkfellner.
5 years 4 months ago #31047

Please Log in or Create an account to join the conversation.

  • Posts: 151
  • Thank you received: 27
hI!
an addendum: in my previous screenshot you see that the server shuts down - this is the effect of my brutal countermeasure. this screenshot now is the traffic if i don't shutdown on server side; this one now is another server that is setup the way W. R.Stevens taught us: bind - listen - accept - recv/send and so on: the first two packets are the connect request (SYN) from SSafari (192.168.4.12) and the accept from the server (192.168.4.1); what follows is a little chitchat, and then (packets 8 and 9) - BLAM (SSafari closes the connection with a FIN). 1.3 ms later it begs for a new connect (packet 9) ... the socket on the server side is, however, dead at that point in time, it was half closed ....

... took me 1.5 weeks to figure this out ...
yours wolfi
Last edit: 5 years 4 months ago by Wolfgang Birkfellner.
5 years 4 months ago #31052
Attachments:

Please Log in or Create an account to join the conversation.

Time to create page: 0.742 seconds