ver2.1.rc1: client/Server error: picConCli says "Adress already in use"

[ozett]

i startet the server with "PixelController.sh" in the PixConServer-subdir which runs without errors. the matrix runs fine.

i thought i can connect with the client, to see only the out-put window on the graphic Desktop under X11. So i startet the pixConClient, but got the error that the adress is already in use. even if i use 127.0.0.1 or the 192.168.14.206 ip of the eth0-interface.

What am i doing wrong? is this a misunderstanding of client/server?

i attach an image with the errormessage:

[ozett]

even i i start the PixelControllerclient.jar file i can not connet and have an error ..

[albydnc]

I have the same problem, did you resolve it?

[GHPS]

What am i doing wrong? is this a misunderstanding of client/server?

You are trying to send the command "GET_GUISTATE". Using that command (or others like "GET_VERSION" or "GET_CONFIGURATION") I also results in an "address in use" error.

The error is false. You can check that using lsof -i:9876 which lists only the PixelController server.

With other commands, however, the PixelController client works fine. Try for example "FREEZE" or "GENERATOR_SPEED".

The reason for this behaviour becomes clear when looking at the debug output:

INFORMATION: OSC Server initialized on port 10009 (buffersize: 61440 bytes) in 37ms
Nov 10, 2019 10:54:24 PM com.neophob.sematrix.osc.server.impl.OscServerImpl startServer
INFORMATION: OSC Server started

The PixelController client is trying to spin up another OSC server instance on port 10009, not on 9876. The purpose of this second, client-side server is to receive the messages from the main server, e.g. the GUISTATE, VERSION or CONFIGURATION..

This is the part that fails.

Update (12.11.2019): The server/client connection for OSC is fresh in ver. 2.1-rc1. It supports the new api OSC commands that depend on a link back to the client (e.g. all 'GET-*' calls).

The port numbers in both the client and the server were mixed up resulting not only in the conflicting address error but also in a failed connection. Plus the protocol was set to TCP in the server.

All issues are fixed in this pull request: Fixed OSC Server/Client connection for new api calls #103

[GHPS]

Since the problem is fixed I suggest closing this issue...