search

warmcat / libwebsockets

canonical libwebsockets.org networking library
https://libwebsockets.org
Other
4.78k stars 1.49k forks source link

Port number problem with lwsws and multiple plugins #838

Closed BoardSemiRigid closed 7 years ago

BoardSemiRigid commented 7 years ago

I am developing some standalone plugins for use with lwsws. (libwebsockets 2.1.0 )

the first is complete, and has two protocols, and works perfectly. the second, when standalone also works , although not yet fully implemented. When I have both plugins running in a single lwsws instance is where we run into problems.

The problem is, each plugin has a conf file in /etc/lwsws/conf.d Each conf file declares two mount points, and associates a distinct html file to the mount point. This all work until that is, we try and use the same port number.

The only way I have managed to get the configuration to accept a single port for both plugins, and all four protocols is to put all the mount points and protocols into a single conf file.

Unfortunately this breaks our software isolation policy, as we are hoping to keep separate conf file for each plugin.

lws-team commented 7 years ago

First don't use 2.1.0, use v2.1-stable branch. There are many backported fixes there since v2.1.0.

I think I can translate what you're saying ("same port number") into "I have to put all my definitions for one vhost in one conf.d file"... that was my intention. So I have two vhosts, I have one file for each in conf.d. The order they are processed (ie, found in the directory) isn't really critical. It's not trying to be 'a config file per plugin' but 'a config file per vhost'. Plugins may be differently configured per-vhost, so it's not like you could #include a single per-plugin config in each vhost.

You should be able to have multiple vhosts on the same port, but the name of the vhost is used then via SNI or Host: header to bind incoming connections on the port to just one vhost based on the hostname it was told to connect to. That doesn't sound like what you want.

Can you help me understand what your anticipated solution you thought existed would have looked like in conf.d? There is no control over ordering of files in conf.d atm...

BoardSemiRigid commented 7 years ago

OK, I hear what you are saying, but it took me long enough to get 2.1.0 installed, I don't really want to go through the pain of installing a new version just yet, although we will be upgrading soon. We are also building for PC and for arm using buildroot, so we need continuity between both builds.

Anyway, on to the problem .. I have attached the two conf files ( added the .txt suffix to allow them to be uploaded as text files) I would like to keep these two files separate, and specify the port in the master conf file.

We don't really need the vhost functionality, but I am usure how to write these configs without it.

wsplugin-card.txt wsplugin-sas.txt

lws-team commented 7 years ago

The v2.1-stable tree just has fixes, no new features or api changes, and v2.1.0 is common to both trees, so there will be no conflicts. If you intend to update in a bit, similarly target v2.2-stable. You can update when you like but if it feels like you have an lws bug, please update before asking about it.

I have an idea for a new feature that might allow this, but it's late here, so I'll look at it tomorrow.

lws-team commented 7 years ago

I looked at this, but it's going to be a major upheaval for a feature I don't see myself using, so I'm going to pass on it. For now you need to use per-vhost config JSON.

I have two suggestions, one is compose the actual conf.d files from your fragments as an external step, the other is what I studied, adapt the parser so he defers vhost creation until he has seen all the files, and he maintains a linked-list of jpargs structs created for each unique vhost name. If he sees an already-existing vhost name, he applies the new pieces to the existing corresponding jpargs struct. Finally after all the files have been processed he iterates the jpargs structs to create the vhosts.

BoardSemiRigid commented 7 years ago

Thanks for looking at this. I appreciate you don't see a use for using it this way, even though it seems perfectly natural to me. We will just have to get our build system to create a single config 'on the fly' to support this type of configuration. At least it I now know I can't do what I want, and will not be wasting any more days trying to find a bug that isn't there. thanks again.