1.05 and 1.5 spawner side by side?

[Micha_cg]

Hi,

should it be possible to start 1.05 and 1.5 spawner side by side and each VfR version is using the right spawner? Last I had a problem, but found no time to test it. Should it work? If not, could be great if it would work.

Regards,
Micha

[wcmansp]

It doesn't work. When you alternately launch the spawners (DRSpawner, XMLDRSpawner) and look at the results with a tool like TCPView you will see they both want to listen on port 20211; this means they can't both run at the same time. Although you can change the port the license server uses, letting you run a license server for both 1.05 and 1.5 on the same machine, there isn't an obvious way to configure the port the spawner clients use.

[Micha_cg]

Doe's it mean, if I change the license server port, than I can let parallel run the two spawners, if I would change ... ? What do you think, would it need a big effort by the developer to change the port usage?

It's so cumbersome to parallel work with 1.05 and 1.5, if every time the spawner need to enabled/disabled at each slave machine. I hope there is a way, on user or developer side.

[wcmansp]

The license server example was only to give a case where the Chaos Group had developed a port selection tool; it doesn't apply to the spawner situation except to show that the Chaos Group has written a port selection tool when they felt one was needed. On the spawners it looks like the (receive) port number is baked in to the spawner executable (it doesn't show in an .ini file, an .xml file, a .py file or in the registry), as well as being baked in as the destination port in the V-Ray for Rhino client -- the V-Ray for Rhino client sends DR data to port 20211 on the DR servers it has listed and the spawners sit there listening on 20211 for things to come in.

Whether it makes business sense for Chaos Group to develop a port configuration architecture for 1.5 (assume 1.05 just stays where it is since that's the old version and not likely to have any further development) is up to them. I'd guess it would probably need to be something more than just being able to run the version they're trying to replace but there may be reasons, looking forward, that they wouldn't want to bake in the spawner port. It's not clear why they wouldn't have baked in a slightly different port number (e.g. 20212) when 1.5 was released since the spawner versions aren't interchangeable. There may have been some thought about it, given there was thought to change the default license server port for 1.5, but, whatever the reason, it stayed at 20211.

As a user solution, it is possible to automate swapping these versions in and out (ie. run one or the other but not both at the same time) using, for example, the freely downloadable Microsoft "PsTools" toolset. These are a handful of applications -- PsExec is one -- that let you exercise a lot of control over remote machines including starting and stopping applications. We run something like this (except we run the spawners as a Windows service so the start/stop tool is a different tool in this suite) and when we want to start the XMLDRSpawners we run a command file that starts them up, then run the job, and then run a command file that stops them; we do something equivalent if we want to run the DRSpawners. It is more time consuming than having them both available concurrently, as you'd requested, but less time consuming than having to visit each machine to start/stop them. Too, we've found the spawners would start to produce blocky jobs if we didn't restart them regularly and let them clear out their local data, so this handles that piece, too.

[Micha_cg]

Thank you for the detailed infos. I didn't know how ports are used, interesting concept. I hope we get a feedback from the developer side and it's possible that the next build is using an other port. It would be the easiest way for the users.

[joe_b]

Hi Micha,

I am going to add entries to our config file so users can change the port that way if they wish. I don't want to automatically change the ports just in case users are already setup with port-forwarding, etc, in their routers/firewalls and don't actually want to use a new port in 1.5 builds.

Here is how it will work: in our root folder we have our ini file( as of 1.5 on windows 7 that would be c:\ProgramData\ASGVIS or on XP c:\Documents and Settings\All Users\Application Data ). This change will create a new section for changing the port. It defaults to the current dr port we use- 20211.

"V-Ray for Rhino.ini"

[DRClient]
port=20211

Also, the first time you run our DRSpawner after this patch is introduced, a new ini file will be made in that same folder.

"V-Ray DRSpawner.ini"

[ServerInfo]
port=20211

So if you want to change the port that is used, just change the number in those 2 files and restart Rhino and your DRSpawner so the changes take effect. Keep in mind, you will need to update the port in both ini files - both the client and server need to be talking/listening to the same port.

I would avoid using numbers lower than 20211 because Chaos Group has some reserved ports in that area, so I would go higher than 20211. For my tests, I was using 20215 and it seemed to be ok.

I will add this new feature sometime in the next few days, so it will not be available in public builds until we do another service release. This probably won't be too far into the future, because we have made a number of small fixes to the product, as well as the installation process.

I hope this helps.

[joe_b]

On the spawners it looks like the (receive) port number is baked in to the spawner executable (it doesn't show in an .ini file, an .xml file, a .py file or in the registry), as well as being baked in as the destination port in the V-Ray for Rhino client -- the V-Ray for Rhino client sends DR data to port 20211 on the DR servers it has listed and the spawners sit there listening on 20211 for things to come in.

Yes, it is currently a hard-coded default value. It didn't occur to me that people would run the 1.05 and 1.5 side-by-side, so it is definitely an oversight on my part. Hopefully, exposing the port in our ini file will help get around this issue.

[joe_b]

Also - just to be clear, this change will only affect the 1.5 builds. Our old 1.05 builds will continue being hard-coded on 20211.

[Micha_cg]

Fantastic, it will help a lot here working on different projects and VfR versions.

Thank you,
Micha

[Micha_cg]

Today I tried it and it works like expected. Great!!!

[Micha_cg]

Hi Joe, if I start the spawner at the master machine for RT usage, than there is no "V-Ray DRSpawner.ini" automatic created. If I manual create one, it works. Maybe it's something to fix.

The info how to change the ports could be added to the migration page also.