Bug 5906 - Having two different display to port allocation strategies is complex
Summary: Having two different display to port allocation strategies is complex
Status: NEW
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: VSM Agent (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: MediumPrio
Assignee: Henrik Andersson
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-05-24 09:56 CEST by Karl Mikaelsson
Modified: 2021-10-19 12:59 CEST (History)
2 users (show)

See Also:
Acceptance Criteria:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Description Karl Mikaelsson cendio 2016-05-24 09:56:14 CEST 
We have two different port allocation strategies when creating a new session. One when DISPLAY is less than 100, where we try /vsm/vnc_port_base+display, and one when DISPLAY is greater or equal to 100, where we do some math to count backwards from /vsmagent/max_session_port.

The native client does not have similar calculations - it relies on what ports the server tells it to use. There's no apparent need to keep two codepaths here.

We have a testbug, bug 1606, that ensures that the second code path still works. This would become a former testbug if we decide to remove the special allocation strategy.
Comment 1 Henrik Andersson cendio 2017-08-28 12:45:19 CEST 
The reason being for two strategies is that an old client didn't reveice which port to connect to, just the DISPLAY and had to calculated the port for itself, the same way as server side. However, this is for an very old client version older than 1.4.0 and we can remove this backward compability.
Comment 6 Henrik Andersson cendio 2017-08-29 08:30:36 CEST 
I need to revert these changes, due to I missed the consequence of breaking a upgrade a installation were sessions with old port allocation was used. Wg. verify_session() will fail.

We can't just change the port allocation without taking this into consideration.
Note You need to log in before you can comment on or make changes to this bug.