I'm using WebORB for .NET and I've had no problems with it running on its default port (2037) in my development environment.
When I deploy it to my staging environment and attempt to access it over the public internet, this port is blocked at many points along the way as it's an uncommon port, and I observe a red WebORB logo with the message "can not connect to messaging server" when I access the WebORB console.
Opening the port is a partial solution, but anyone accessing WebORB's applications will also need to ensure they're not blocking that port... so it's not really a proper solution.
I have managed to get WebORB running on port 443 (which is used for SSL, and therefore almost never blocked), but only if I have no other sites in IIS with a port 443 binding.
This is also unacceptable as I will eventually have another site on the same server with a port 443 binding.
So, my question is: is it possible to run WebORB on port 443 (or 80), when another site in IIS is also bound to that port?
Update following answer
I'm on Server 2008R2, and therefore IIS7.5, and I'd prefer to run my WebORB website in integrated mode. The instructions in the first article mention adding a wildcard script map for Isapi.dll - this will only be invoked in classic mode.
I've added all of the entries that the article suggests, and have configured my site to use port 80. There are other sites bound to port 80 in IIS.
When I navigate to the WebORB console, I'm observing the same behaviour I saw before adding the new RTMPT handlers - a red WebORB logo and no entries appearing in the "Messaging Server" panel. However, I do see the "Bad request, only RTMPT supported." message when navigating to ~/open/1, and my diagnostics.aspx page looks fine.
In the log I see the following:
...
WEBORB INFO:adding child scope for - \root
WEBORB INFO:scope registered - \root
WEBORB INFO:WebORB Messaging Server 4.4.0.0 (c) 2003-2010 Midnight Coders, Inc.
WEBORB INFO:is running - False
WEBORB EXCEPTION:System.Net.Sockets.SocketException (0x80004005): An attempt was made to access a socket in a way forbidden by its access permissions
at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)
at System.Net.Sockets.Socket.Bind(EndPoint localEP)
at Weborb.Messaging.BaseRTMPServer.start()
WEBORB INFO:shutting down WebORB Message Server
WEBORB INFO:loading type: Weborb.Management.ServiceBrowser.Browser.AssemblyBrowser
...
Do I need to alter any other config to enable the console to use RTMPT?
Also, given that incoming requests must be over HTTP, is there no way to consider host headers?
what you are asking is whether you can route RTMP connections via port 80 or 443. Since these ports are managed by IIS, the incoming connections must be HTTP-based. Your RTMP clients can connect via port 80 or 443 by using RTMPT or RTMPS respectively. In that case, you do not need to "run WebORB on these ports", but instead configure WebORB to use RTMPT or RTMPS. Please see the following doc:
Configuring RTMPT in WebORB: http://www.themidnightcoders.com/fileadmin/docs/dotnet/v4/guide/rtmpt.htm
Configuring RTMPS in WebORB:
http://www.themidnightcoders.com/fileadmin/docs/dotnet/v4/guide/rtmps_support.htm
Hope this helps.
UPDATE: If the goal is to route the management console's traffic via RTMPT, it will not work with the currently released version. The console can dynamically determine the RTMP port, but it will stick to the RTMP protocol and does not have the code to switch to RTMPT. This is something we will look into.
As for the exception you're getting, it occurs because the port you specified in Global.asax is already taken by some other process.
Related
I have one windows server already running sharepoint on 80/443 and the site works correctly.
We're trying to add more functionality by installing NodeJS and Apache
I've set apache to listen on 8080 and the default website comes up.
Node is running on 3000 and I can access the explorer that way as well.
My questions come from this. The server has a complete certificate chain installed on it and https://:8080 comes up correctly, but I can't get the node stuff to work on https: Secondly it appears while I have proxy pass set up correctly within my httpd.conf, either something is wrong within that as if I goto the https://:8080 /api/and anything beyond that, I get 503 errors and the page can't be displayed.
I'm unsure what I'm doing incorrectly here as from reading the documentation on proxy module, it seems that everything is setup and configured correctly.
Netstat shows listening on 3000 and 8080 and 80/443 for my SharePoint farm.
I had to configure the ssl settings for the proxypass to use the IP address of the local machine. After doing that I was able to connect correctly.
This allowed for connecting on :3000 via telnet to the localmachine and allowed for explorer to be viewed with https://:8080 the correct way enforcing our certificates.
I have a nodejs application running on port 3000. I wanted to host it on Linux environment. So I installed nodejs in it. It's working fine but I should specify the port each time.
example: mydomain.net:3000/url_i_want,
How can I avoid this. and also when running my app like that, all users are kind of connected to each others. If one of them disconnect all other users are. If one of them change page all others have there pages changing. Is it because they are all listening to the same port 3000 ? I searched and found that it can be related to PM2 and Nginx. Is it the solution ?
Whenever you load a URL without specifying the port number, the browser defaults to 80, because 80 is the default port number for HTTP.
So if you load http://stackoverflow.com/questions, the browser "converts" it to http://stackoverflow.com:80/questions.
If you don't want a port number to be specified to access your website, your app should be listening on port 80, instead of 3000.
However, it is not recommended for Node apps to directly listen on port 80 (although they very well can).
What you can do is use a front-facing proxy such as nginx, which accepts connections to the host's port 80, and then redirects the request to localhost:3000, where your app is listening.
It is best to ask one question at a time.
As for your second question, unless you are using some sort of "remote syncing" framework, that sort of behavior is unexpected. I would suggest posting a separate question for that issue with more details about it.
We're re-writing our services from ASMX -> RESTful using ServiceStack so there's a short term need to keep IIS and classic services running on port 80. Also, some of our customers host more than one web app (e.g. company intranet) under IIS listening on port 80.
My application needs to be distributed to hundreds of customers, so I'd like to move away from the IIS dependency in the interest of making my deployment of updates simpler - if possible. We also have many customers who have setup special forwarding in their routers for port 80, so listening on a different port for SS services would cause a lot of deployment pain - not to mention most firewalls are more lenient with port 80 traffic.
I have two possible related issues:
1. When I can get SS to fire up on port 80, I get "handler not found" for routes that would otherwise work on another port.
2. While debugging (start / debug / stop / restart), eventually a listener registration appears to "stick" and I end up getting:
System.Net.HttpListenerException (0x80004005): Failed to listen on prefix 'http://*:80/' because it conflicts with an existing registration on the machine.
at System.Net.HttpListener.AddAllPrefixes()
at System.Net.HttpListener.Start()
at ServiceStack.WebHost.Endpoints.Support.HttpListenerBase.Start(String urlBase) in C:\src\ServiceStack\src\ServiceStack\WebHost.Endpoints\Support\HttpListenerBase.cs:line 122
at FieldCommService.FieldCommService.ConfigureServices() in e:\Development\Source\Hg\fieldcomm\src\Services\FieldCommService\FieldCommService.cs:line 305
at FieldCommService.FieldCommService.Startup() in e:\Development\Source\Hg\fieldcomm\src\Services\FieldCommService\FieldCommService.cs:line 84
I won't rule out hosting the service under IIS as a solution, I just prefer not to take on/continue to take on the configuration and deployment pain IIS comes with.
I have two questions:
1. Is listening on :80 as a self hosted service possible [with AppHostHttpListenerBase]?
2. In the intellisense for AppHostHttpListenerBase, it's noted that this class is designed to allow listening on port 80 next to IIS, but that "admin user privileges" are required. What does this imply under Windows running as a Service? An identity belonging to the Administrators group? Or simply "Local System"?
When you right-click a Web site in the Microsoft Internet Information Services (IIS) Microsoft Management Console (MMC) snap-in, and then you click Start, the Web site does not start and you receive the following error message:
The process cannot access the file because it is being used by another process.
What have to do.
To resolve this issue i got this solution:
You must use the Netstat.exe utility at the command line to see if another process is using port 80 or port 443.
But how to ensure that is these Ip are in use or not ? in terms of status ? What should its status ?
Second solution is : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\ListenOnlyList.
But this key is not found .
Lalit, this should probably be on ServerFault.com as this is more of a server administration question. With that said, you probably have more than one website listening on port 80 or 443 without the use of host headers. When using port 80, you cannot have more than one site on the port without specifying the domain name(s) to use in your website bindings. 443 (HTTPS) gets a little more tricky as you typically cannot have more than one site use 443 even if you are using host headers (there are exceptions like wildcard SSL certs). This is due to IIS not being able to read the host headers and know which SSL cert to use to decrypt them since they are encrypted.
http://support.microsoft.com/kb/890015 for more information
More links:
http://support.microsoft.com/kb/308163
Google
Finally i keep error as it is and I reinstall IIS and required software.
Prologue: I am running windows Server 2008 R2 on a Virtual Machine. This virtual machine image has been happily hosting TeamCity on port 80 for several weeks. This TeamCity server is accessed by others on the network by visiting a url (pcname.domain.com).
The Issue: It seems corporate decided to push some updates to my machine over the weekend. It seems this round of updates decided to install/update IIS. Low and behold, visiting the URL mapped to the TeamCity server actually takes me to the stock IIS7 page. Visiting url/login.html brings me to the TeamCity log-in page.
Attempts: First off, I changed the TeamCity port to 8080 and was able to access it at url:8080 (or localhost:8080). However, it is imperative to me that people can access the server without providing a port... so I change TeamCity server port back to 80 and set off to try and fix this IIS problem.
Since then I have uninstalled IIS7 by removing the role and services from Windows - I am now hosting "0 roles". I have removed every trace of IIS from my PC, but visiting localhost still gives me 404 not found (instead of server not found or just my TeamCity page).
My Question: How do I prevent Windows Server 2008 from trying to host some default crap on port 80 so that my TeamCity server can be seen again?
EDIT: After performing netstat -ano, the only PIDs associated with port 80 are '0' and '4' (system and svchost!)
In windows the usual suspects using port 80 are IIS itself, and maybe the Web Deploy Agent Service if installed (but it could have any other app bound to that port). The PIDs 0 and 4 just tell you that the applciation using that port is running as a service. If you do not need any of this (IIS, web deploy, etc), go to Services and disable them, the port should be free to bind after that.
You can use net sh http show servicestate | findstr HTTP to reach the address and port binding information.
A simple solution (one that I am also using in a production server with multiple apps) is to set up a proxy based on either the domain or the URL path itself (see here how to with nginx).
Hit command, netstat -ano in an elevated command prompt to see what applications are listening on which ports. This command will show you the PID of the process that is listening on port 80. Now, open the Task Manager -> Processes tab. From the View -> Select Columns menu, enable the PID column, and you will see the name of all the processes those are listening on port 80. You can kill the listed tasks. Mostly applications like, World Wide Web Publishing service, IIS Admin Service, Web Deployment Agent Service may use the port 80 in Windows Operating System.