I'm looking for suggestions about approaches to allow multiple applications to use port 80 for communication.
I know it's impossible, or at lease not sensible to have multiple applications to actually bind to port 80, however, I've seen appliances when there is a device that provides both a web interface (HTTP) and RTSP with RTP using port 80.
I have two ideas on how this is achieved:
Are those custom made apps that implement all the functions?
For example the same binary is used for a web server and a RTSP server. That seems kind of limiting due to the fact that you would have to do sever modifications to already developed apps if you want, for example, Apache and openSSH both on port 80.
Are there a "port 80 multiplexers" sort of a pattern?
For example, a parser application that listens to port 80 and depending on the header of the received package, passes the package to the required application.
Found some related references, will give them a try.
https://bbs.archlinux.org/viewtopic.php?id=99457
http://www.rutschle.net/tech/sslh.shtml
I really don't think this is possible in a standard way: port number is actually the one that allows multiplexing among different applications in TCP and UDP protocols. More generic, TSAP, Transport Service Access Point allows multiplexing at the transport layer. TSAP is the port in protocols such as TCP, UDP, or SCTP.
One reason you may want two applications listening on the same port is that a second application can monitor or process in some other way the messages received, and eventually processed, by the first one. In this case, using pcap library other applications could read messages received by the main application that will probably response those messages.
Netfilter can also be useful, http://www.netfilter.org/
However, if you intend two applications to respond messages that arrive to the same port, that would be tricky and would have dependency on each application.
In this response I'm assuming you are thinking of applications listening to the same port at the same IP address. Something different is working with multihost servers where two applications could listen to same port number in different IP addresses.
Related
If I am building a WebRTC app and using a Selective Forwarding Unit media server, does this mean that I will have no need for STUN / TURN servers?
From what I understand, STUN servers are used for clients to discover their public IP / port, and TURN servers are used to relay data between clients when they are unable to connect directly to each other via STUN.
My question is, if I deploy my SFU media server with a public address, does this eliminate the need for STUN and TURN servers? Since data will always be relayed through the SFU and the clients / peers will never actually talk to each other directly?
However, I noticed that the installation guide for Kurento (a popular media server with SFU functionality) contains a section about configuring STUN or TURN servers. Why would STUN or TURN servers be necessary?
You should still use a TURN server when running an SFU. To understand diving into ICE a little bit will help. All SFUs work a little differently, but this is true for most.
For each PeerConnection the SFU will listen on a random UDP (and sometimes TCP port)
This IP/Port combination is giving to each peer who then attempts to contact the SFU.
The SFU then checks the incoming packets if they contain a valid hash (determined by upwd). This ensures there is no attacker connecting to this port.
A TURN server works by
Provides a single allocation port that peers can connect to. You can use UDP, DTLS, TCP or TLS. You need a valid username/password.
Once authenticated you send packets via this connection and the TURN server relays them for you.
The TURN server will then listen on a random port so that others can then send stuff back to the Peer.
So a TURN server has a few nice things that an SFU doesn't
You only have to listen on a single public port. If you are communicating with a service not on the internet you can just have your clients only connect to the allocation
You can also make your service available via UDP, DTLS, TCP and TLS. Most ICE implementations only support UDP.
These two factors are really important in government/hospital situations. You have networks that only allow TLS traffic over port 443. So a TURN server is your only solution (you run your allocation on TLS 443)
So you need to design your system to your needs. But IMO you should always run a well configured TURN server in real world environments.
I'm planning on using a wsDualHttpBinding for a WCF service with callbacks. The clients will be a windows form application communicating to the service over the internet. Obviously I have no control over the firewall on the client side, so I'm wondering what is the proper way to set the ClientBaseAddress on the client side?
Right now in my intiial testing I'm running the service and client on the same pc and i am setting the binding as follows
Dim binding As System.ServiceModel.WSDualHttpBinding = Struct.Endpoint.Binding
binding.ClientBaseAddress = New Uri("http://localhost:6667")
But I have a feeling this won't work when deploying over the internet because "localhost" won't translate to the machine address (much less worrying about NAT translation) and that port might be blocked by the clients firewall.
What is the proper way to handle the base address for callbacks to a remote client?
some one tell me if i do not specify ClientBaseAddress then WCF infratructure creates a default client base address at port 80 which is used for the incoming connections from the service. Since port 80 is usually open to firewalls, things should just work.
so just tell me when win form wcf client apps will run then how can i open my custom port like "6667" and also guide me what library or what approach i should use as a result response should come from client side router
to pc and firewall will not block anything. please discuss this issue with real life scenario how people handle this kind of situation in real life. thanks
The proper way is to use TCP transport instead of HTTP transport. Duplex communication over HTTP requires two HTTP connections - one opened from client to server (that's OK) and second opened from server to client. This can work only in scenarios where you have full control over both ends. There is simply too many complications which cannot be avoided just by guessing what address to use like:
Local Windows or third party firewall has to be configured
Permission for application to run - listening on HTTP is not allowed by default unless UAC is turned off or application is running as admin. You must allow listening on the port through netsh or httpcfg (windows XP and 2003) - that again requires admin permissions.
Port can be already used by another application. In case of 80 it can be used by any local web server - for example IIS.
Private networks and network devices - if your client machine is behind the NAT the port forwarding must be configured but what if you have two machines running your application on the same private network? You cannot forward from the same incoming port to two machines.
All these issues can be avoided mostly only when you have control over whole infrastructure. That is the reason why HTTP duplex communication is useful mostly for intranet scenarios and why for example Silverlight offers another implementation where the second connection is not created and Silverlight client instead polls server continuously to check if there is any callback available.
TCP transport requires only single connection from client to server because TCP protocol is natively duplex so the server can call back the client through the same connection. When you deploy a public service you usually have control over infrastructure on the server side so you can make necessary changes in configuration to make it work.
I think this also answers your previous question.
I'm building a WCF P2P service using the PNRP functionality.
I see that I can assign a port to the Bindings... but most of the examples do not.
Is there a reason I should or shouldn't give it a port?
If you don't assign a port, WCF will choose a random available port automatically. The local port information is broadcast to peers as part of the PNRP process, so setting a local port explicitly is more to make your application predictable than anything else.
I usually set my ports explicitly so that I can document them to my customers. This is especially important when a customer uses a 3rd party firewall that I can't easily configure in code. If your app assigns a random port, they won't know what port to unblock in their firewall software.
I'm interested in one WCF server exposing both HTTP and TCP interfaces. It'll be used with Silverlight clients, so the thinking is that the HTTP interface will be for secure communications while TCP will be used the rest of the time.
Is it possible for these two interfaces to use the same port in their endpoints, e.g. http://localhost:9000/ and net.tcp://localhost:9000/?
No this is not possible. If you have the TCP port sharing service enabled, you can have multiple services listening on the same TCP port. Windows HTTP listener will also allow you to have multiple services sharing a common port (for example, a console application and IIS can both listen on port 80 at different URL's). But you can't use multiple bindings on the same port.
But I don't really see the advantage of doing that anyway. I would personally leave the HTTP endpoint on port 80 and of course your TCP endpoint is restricted to an upper port range. I'm not sure what scenario you're trying to enable though.
You can only have one "listener" on a TCP port, so unless the WCF server does some sort of protocol-level multiplexing (i.e. if it reads in an HTTP header, send it to the HTTP handler otherwise send it to the "raw" handler), you'll have to use different ports.
Of course the quickest way to find out is to configure your server with both of these interfaces and the same port, and check your logs for errors. Chances are each one will be attempting to bind to port 9000 from their own thread or process, and the second one will fail.
I'm curious why is it more pervasive. Does it has a better API?
I remember long ago when i first learned about NAT (i used it for sharing a dialup 14.4kbps modem), i thought that someday every home would have a router with NAT included, but it would "obviously" need also a SOCKS process to be able to open listening ports. When broadband started appearing, it was nice to see NAT as a common feature, and I supposed that SOCKS would be an extra, and slowly become more and more common... but nothing! i had to manually forward ports. then appeared that uPNP, but very few 'serious' applications support it, mostly P2P sharing, games, and some IM.
I still haven't seen any home router to include SOCKS (apart from Linux-based firmware upgrades, of course). does anybody know why??
edit:
as Vartec noted, UPnP is a zeroconf and service discovery, not proxy service. now i know that what i'm referring to is IGD protocol, the NAT traversal service present in home routers, and discovered via UPnP. so, my question would more properly be "Why IGD/UPnP instead of SOCKS?"
SOCKS has limitations compared to UPnP. Generally SOCKS requires configuration on each client and isn't transparent to applications (system-wide socket SOCKSification isn't installed/enabled by default on Windows), while NAT even without UPnP mostly works transparently and without any additional client configuration for outgoing TCP sockets and outgoing UDP.
NAT with UPnP also supports server TCP sockets better than SOCKS: SOCKS can only accept a single connection with its BIND request, which is okay for receiving a single TCP connection in a protocol like FTP, but useless for running a server that needs to accept many connections from many clients. SOCKS 4 also had a 2 minute timeout on the BIND request, but a server generally cannot know when the next client will try to connect.
Low-level TCP settings (eg. TCP Nagle, traffic class) also don't work across the SOCKS proxy, but they work through a NAT.
As far as I know, UPnP is zeroconf discovery type of protocol for devices in local networks, while SOCKS is tunnel-proxy server. They are completely different, actually I don't see anything, that they would have in common.
these are two different things, socks is a protocol that allows you to route tcp and udp (socks v5) through a proxy server and it's for outgoing connections, routers dont have anything to do with this (except they are acting as a proxy too)
the IGD of upnp is an 'api' that allows you to tell your router that you want to open a port and foward it to a computer, this is for incoming connections.. my linksys came with upnp enabled by default and one app i know to use this is msn messenger (maybe only for file transfers)