Bug 5906

Summary:	Having two different display to port allocation strategies is complex
Product:	ThinLinc	Reporter:	Karl Mikaelsson <derfian>
Component:	VSM Agent	Assignee:	Henrik Andersson <hean01>
Status:	NEW ---
Severity:	Normal	CC:	astrand, hean01
Priority:	P2
Version:	trunk
Target Milestone:	MediumPrio
Hardware:	PC
OS:	Unknown
Acceptance Criteria:

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.