|
|
It is expected the program do not close when there is active connection, In this case it reduce to the task bar instead. The server can only detect a disconnection from the client by trying to send periodic message and look for failure. This is done only when the option is set in Setup / General / Server. Can you ensure that "Client connection keep alive" is checked. You can also monitor and close the session from the menu View / Server information. For me this work normally using the latest beta 4.3. |
|
|
Hi Patrick, I just tested downgrade/upgrade (4.3.4327 x64 <-> 4.3.4495 x64). SkyChart 4.3.4327 x64 seems to work flawlessly. Checking/unchecking "Client connection keep alive" checkbox makes no difference: so I assume the clients I'm using properly close the connection. 4.3.4495 doesn't work and keeps connection alive: each communication attempt by the same client adds a new connection. I'm on W10. I hope it helps. Thanks again and Clear Skies! Armando P.s. Also SkyChart 4.3.4370 x64 doesn't work. |
|
|
I no more have this old version 4.3-43xx. I am interested if you can give me the corresponding git commit. Open Help / About, this is the hex string at the end of the version number. I am also interesred by the compilation date. With this information I can find what changed between 4327 and 4370. |
|
|
4327-358a541b 2021/02/15 4370-433ce655 2021/07/05 |
|
|
I not find any evident change to this function within this range. Can you repeat the test I do to be sure how this work on your system. - in Windows optional features, be sure telnet is activated - start CdC, open the menu View / Server information - open a command line window - type: telnet localhost 3292 - look the connection show in CdC - close the telnet window, look the connection is closed in CdC Can you also tell me what client application you use so I can also make some test with them. |
|
|
Hi Patrick, I just tested a connection by telnet Putty client and it worked. I also sent some commands (GETRA, GETDEC, GETRA F) and CDC properly answered. By CDC server info panel I found connection kept on as expected till the end of communication by Putty. I also checked/unchecked the CDC option to keep connection alive and it works as expected. Then I switched to NINA and it also worked flawlessly. Maybe something more is required to reproduce the issue. Strangely when submitting the issue it occurred systematically and it was solved/reoccurred by downgrading/upgrading CDC without any other change. Another user confirmed the same issues (by using NINA as client). I used also another client (developed by myself) while testing with the same results. So I'd exclude bugs affecting the clients to figure out what can mess up the communication... |
|
|
Maybe there is timing problem if too much connection are initiated in a short time. CdC expect a permanent connection for a given application, as show in the example scripts https://github.com/pchev/skychart/blob/master/skychart/sample_client/python/testObsList.py But it look like your application and NINA create a new connection for every command. I will make more test to improve working on this condition next week. |
|
|
FWIW this is what I found with my small utility (I just sent GETRA and GETDEC commands while testing, so just 2 connections in a short time) and NINA: 4327-358a541b (2021/02/15) - never had any issue 4370-433ce655 (2021/07/05) - not sure 4481-e549d453 (2022/04/04) - never worked as expected 4495 (latest beta) - never worked as expected I hope it helps to fix the code. Thanks again! Armando |
|
|
I have some time to return to this problem today. I find a case where a very short lived session can crash the connection thread, making some random error after that. You can try a fixed version available here: https://vega.ap-i.net/tmp/skychart/ If this not fix your problem I really need a way to reproduce what you do, preferably your test utility or precise instruction for NINA. |
|
|
I just tested. Unfortunately the issue still occurs. You can simply reproduce it by NINA by trying to acquire CDC coordinates from the framing panel. You've to set Cartes Du Ciel as the preferred planetarium software and set server port and address accordingly. image.png (41,358 bytes) image-2.png (67,110 bytes) |
|
|
I make some test with last version of NINA and CdC beta. For me it work fine when in CdC the option Setup / General / Server / "Client connection keep alive" is not checked. In this case NINA correctly handle it's session connection to CdC, automatically closing the session after some time. It is only in the case I quickly repeat the click on the button "Get coordinates..." that it create some extra connection, but they are removed soon. If the option "Client connection keep alive" is checked it not work correctly. Only the first connection work, after that a new click on the button make it wait for a long time until it show a connection error. When this option is checked CdC periodically send a single character "." to the client to detect if it is still alive. This is very efficient to detect a telnet connection that was killed for example. But it look like this make perturbation in NINA own processing of the connection so it is necessary to not check it. |
|
|
Just my 2 cents here because I've found a similar (but not 100% exact) problem so it may or may not be the issue. I'm adding CdC support to a software I normally use to take pictures in the field (developed by myself, and it's a mess)... and since commands are sent quite infrequently I opted for a connect/write/read/close operation. While testing the code to process replies, I've noted the following: If I don't fully read from the socket what CdC sends back, when I close the connection (client side) CdC ends up in some strange state, and then I can no longer connect to it, and I have to close and reopen it. This happens with beta version 4531 on Windows 10, but not with version 4.2.1 4073 on Windows 7 (which seems to work fine). Hope this helps Ciao Angelo |
|
|
Angelo, Thank you for this information. Can you try wit the beta version 4531 and be sure "Client connection keep alive" is not checked. Can you also try to send the QUIT command to CdC before to close the connection? this must ensure a clean termination of the session for CdC. It can help me a lot if you can extract the code you use to connect to CDC in a small test program I can use for testing and debugging in CdC. |
|
|
I look more in detail in the code history to try to understand why I do it this way, sending a small message to detect a connection lost. This date back to the first implementation 20 years ago when I replace DDE by TCP/IP. Maybe at this time a socket error was not returned reliably... and because this was working I never change it. From my testing today the socket error notification is very reliable and work in all my testing with both Linux and Windows. So I make a change to remove this "keep alive" option and all the related code. Testing with NINA work very well, the connection session is so short you cannot even see it in the CdC server information window. Repeating click on the NINA button as fast as possible work every time with no error. So please forget my previous message and try with this version 4.3-4532 I put here: https://vega.ap-i.net/tmp/skychart/ Please test and look at "View/Server information" to be sure no inactive connection are kept back. |
|
|
I'll check with that version tomorrow since I cannot test this tonight. But I did a few other tests after having written my message this afternoon, and I've found these things (that may or may not help): 1) When CdC is in that "strange state" in which I can no longer connect to it, sometimes (not always) there is a connection listed in the Server Information window and Cdc minimizes and does not close. 2) When this happens, if I try to force closed that connection (by right clicking on it) I get an "Access violation". Continuing, the socket is no longer listed, but I still cannot connect to CdC 3) In my case, the problem was caused by the "OK! id=1 chart=Chart_1" message I was not expecting. If my code received that message before the expected answer, it discards it. But if it's AFTER the expected answer it will not be read. My code (in vb.net) closes the socket with an option which is supposed to force a RST and not a clean close, but: a) using a clean close seems not to make any difference, and b) I did not check what actually happens because sniffing the loopback interface on windows is difficult. Tomorrow I hope I'll have time to build a small program reproducing this problem to upload here. Regarding the "Client connection keep alive:" it's checked on my home PC (where the problem happens too) and should also be checked on the PC I used before (I've never changed it). Ciao Angelo |
|
|
Hi, Just checked with the 4.3-4532 version and it seems to have fixed (at least) my problem. From a quick test with my code, if I leave something unread when closing the connection, CdC will continue operating correctly, while 4531 would have stopped accepting connections. I've not yet put together the small test program you asked before, but if you still would like to have it, let me know. Thanks as usual Ciao Angelo |
|
|
Hi Angelo, Thank you to test this version and good it fix your issue. I not think I need the test program now you confirm it work with your application. I let this issue open for some time if Armando want to test or make comment about this solution. |
|
|
Hi Patrick, I just checked (4.3-4532 x64 release), the issue seems to have been solved and N.I.N.A. properly acquires the coordinates. Also my utility properly gets coordinates from (and communicates to) CDC. Thanks again and Clear Skies! Armando |
|
|
Thank you for testing. It is good the communication with CdC is now more reliable. |
- Anonymous
