When establishing the server-side of grpc you can specify that it automatically chooses an unused port for you. However, if you use this feature then how will the clients know which port to connect to since it is dynamic?
In my particular case, I'll be using local ipc, though I suppose the question can pertain to remote ipc as well.
https://grpc.github.io/grpc/csharp/api/Grpc.Core.ServerPort.html
They must be told.
PickUnused is a convenience to save the server (developer) determining an available port. It does not change nor simplify the client's port determination.
Clients need to know a remote host address (if any) and a socket/port in order to connect to a server.
Host addresses can be looked up (e.g. DNS) and the only solutions for the socket's discovery are:
Static (not PickUnused)
Well-known e.g. HTTP on 80 and HTTP/S on 443
Service|Port lookup (server publishes its port to some service discovery1)
Port scanning
1 -- Perhaps another gRPC service using PickUnused 😃 Turtles, all the way down!
Related
I am new to openthread I have some interrogations about Thread device connectivity to cloud server.
Cloud server <------------> local internet <-----> Thread network
ipv4 Router(firewall) ipv4 OTBR ipv6
Our products (Thread network) will be built in clients networks which have various internet routeur/firewall and network configurations.
Using UDP(DTLS) to PUT/GET/POST... (CoAP) data on cloud server did you experience any issues with UDP timeout parameters ? Will I need to do hole punching to ensure cloud server can contact end device ?
As i understand it, from cloud server point of view, he can only Rest method on the Border Router CoAP server, as he don't know end device ipv6 and i don't plan to do port forwarding ?
Would allowing cloud server to contact specific thread end device require ipv6 tunnel ?
To finish, if im spouting nonsense, please enlight me about how you build your connection with cloud server :) !
Thank you for reading this post, I hope I was clear.
Best,
Let me try to sort some things.
There are two general approaches:
the clients from your local network starts the communication and the cloud-server answer. The router acts as NAT. In that scenario there are usually timeouts on which the "NAT" rules expires and the traffic from the cloud-server will not be forwarded to a client in the local network.
the cloud server starts the communication. That traffic is sent to your router, and the router and forwards the message to a local network node. This approach requires usually configuration of the router (there are some protocols to do that from your client devices, but even that requires to enable that function). You configure a port on the router to forward the traffic to a specific address+port of your clients. Though this requires either configuration of a lot of ports (for each client one port) or one coap-node, which acts as coap-proxy and configuration for that.
The first approach will end up in a lot of traffic just to keep the NAT open.
The seconds requires either a lot of configuration or a "coap-proxy", where I'm not sure, if you can find a proper implementation.
(By the way, the router may have only a temporary fixed ip-address, e.g. one change peer day. So the second approach requires rare updates of the router's address in your cloud server. And sure, there are some Internet provider, which doesn't offer that your router is reachable, because they add a extra NAT.)
I know there needs to be a STUN/ICE/TURN server to find the IP addresses of the peers involved in a WebRTC communication. However, even after IPs are found, how do the peers actually talk to each other independently without having any ports opened?
If you build a website, you usually have to open the ports on your server to have others access your site. What's the magic that is happening in WebRTC that I'm not understanding?
There are several strategies to do this: one possibility is for the client to explicitly open a port via UPnP. I'm not sure if any current WebRTC client does so, but in general networking this is a possibility.
Failing that, the STUN server kicks in. There are several hole punching techniques it can try; read the aforelinked article for the gory details. In short though, a firewall will usually open a port for outgoing traffic (because it needs to receive responses), so by establishing an outgoing connection to a known target and then making note of the port that was opened it is possible to open a port.
Failing even that, a TURN server is necessary. This server is publicly accessible from both peers, even if both peers cannot see each other. The TURN server then will act as a relay between the two. This somewhat negates the point of a P2P protocol, but is necessary in a certain percentage of situations (estimates range around 10%-20%).
The original Question is "what/who creates the sockets?"
The browsers creates the socket and bind them to a local port for you
during the "ICE gathering".
Wether you use any stun/turn server or
not, each candidate generated during the ice gathering has a
corresponding port open.
Those ports are usually open only for 30 mn
after which they are revoked to avoid an attack by someone using old
and/or spoof candidates. These 30mns are not specified in any
specification and are an arbitrary choice by the browser vendor. -
The next question is "how does the remote peer know about which ports are open".
through the ICE mechanism, which for each media will generate potential candidates and send them to the remote peer through your preferred signaling channel.
ICE candidates (which are one line of SDP, really) have a "type". if this type is HOST, then your candidate is a local candidate generated without the use of any stun or turn server. is the type is SRFLX, then you have used a STUN server to add the mapping between your local IP:port and your public IP:port. if your type is RELAY, same thing with a TURN server.
of course, using the local IP:port HOST candidate will fail unless the remote peer is on the same local network.
From the browser and local system point of view, the socket is open on the local IP:PORT anyway. Hence, opening the sockets and finding out on which port a remote peer should connect to connect to the socket are separate problems handled separately.
The Final question is: "can it really work without a STUN server"
Most probably no, unless you are on the same sub network.
Stats shows (http://webrtcstats.com) that even with a STUN server, you still fail in 8% of the case, for the general public. It's much more in enterprise, where you'd better have advanced turn (supporting tunneling through TCP/80 and TLS/443) and even support for HTTP proxy's CONNECT method.
I've been investigating networking for use in a two-player game I'm writing, and I'm still not clear on when a device must have a port forwarded in order to communicate with the outside world.
From what I've seen in other games, port forwarding is always required in order to host a server, but is not required on the client. In addition, there are other situations, such as skype (which, to my understanding is ultimately client to client), where neither end must forward a port.
So my question is, in over-the-Internet communication, when is and isn't port forwarding necessary, and what steps can i take as a developer to make it so my users don't have to worry about it? Thanks in advance!
Port forwarding is needed when a machine on the Internet needs to initiate a connection to a machine that's behind a firewall or NAT router. If the connection is initiated by the machine behind the firewall, the firewall/router automatically recognizes the reply traffic and sends it to the machine that opened the connection.
But if a packet arrives on the external interface, and it's not a part of such a connection, the router needs to know what to do with it. By default, it will reject it. But if forwarding is configured for the port, that tells it what internal machine to send it to.
Put another way: you need port forwarding if you want to run a server behind the NAT firewall/router, you don't need it if you're just running a client.
There is reason why Skype don't (not always) need manual setting of port forwarding:
When you install Skype, a port above 1024 is chosen at random as the
port for incoming connections. You can configure Skype to use a
different port for incoming connections if you wish, but if you do,
you must open the alternative port manually.
If the port chosen for incoming connections becomes unavailable, by
default ports 80 and 443 will be used as alternatives. If another
application (such as Apache HTTP server or IIS) uses these ports, you
can either configure the application to use other ports, or you can
configure Skype to not use these ports.
Port forwarding is must if you host a server.
You can use same technique as Skype...
I am not sure if there is any other option...
Port forwarding (occurs) when a NAT, firewall or some other device blocks communication on all or some ports.
To answer your question as an example, most commercial routers use NAT to allow multiple people to use the same IP(As view from the outside world) provided by ISPs. Most ISP's use NAT to allow multiple customers to use the same IP(As viewed from the outside world). To get this to work, the NAT changes the internal IP and the port number of a communication to THE(there is only one for the entire sub network) external IP and a new port number. By doing this, the router/isp/ect can tell which internal IP and port each external communication goes to.
Anytime one of the computers communicating over the internet are behind a NAT, port forwarding is required. I'm sure there are way more situations than this, and the solution to each can be quite complicated. But this covers the vast majority.
everyone! I have a list of http proxy servers, some of then may stop running http proxy process. Of course, there are two cases: the port is not listened any more; and the port may be listened for another service. I have to write a program to judge if a given server is still running http proxy. How can I do that? If I can connect to a port, how can I judge whether it provides http proxy service or not? Is there protocol relative thing I can employ?
Most proxy servers use port numbers like 8080, which are not assigned to any other services. In those cases, if you can connect, it is usually safe to assume it is still a proxy.
In the case that the proxy server uses a standard port like 80, you may want to make a single request to a known host on the internet. That way you can know that it is still forwarding requests to the outside.
If you're trying to see what services are available on any given server or port, something like nmap may be useful. nmap can usually identify the type of service running on any given port.
IMPORTANT: Running a full port scan on a remote host is (almost always) illegal unless you have written permission from the owner of that host. Sometimes it is illegal even if you have written permission.
Scanning one targeted port using nmap is probably okay.
I don't really understand the differences between the different ports. I couldn't find any useful resources online that would go into detail about it. From what I can understand, it acts as some kind of filter that blocks out any other request not using the same port number.
When will I, if ever, need to change the port number when typing in a website in my browser? What about if I am running my own website? Are there any risks I take when using port 80? As in, are there ways to use different port numbers to hack into a website?
And since a Simple Mail Transfer Protocol uses port 25, could I use this knowledge to send emails using self written programs?
By conventions and standards, defined protocols generally listen on defined ports by default. You can set any service to listen on any port you want, just be aware that changing from a standard port means that standard tools would need to be explicitly told to use your non-standard port.
For example, if you run a web server then by default it's probably listening on port 80. So all someone needs to do to visit your server is use the address:
http://www.yourserver.com
However, if you change it to listen on a non-standard port, such as 81, then any user who wants to visit your site will need to specify the port number:
http://www.yourserver.com:81
The standard convention of just using the address wouldn't be sufficient, because you've broken convention. Now, this is fine if you don't want people randomly using your site and only want it to be available to people to whom you've told the port number. This is called "security through obscurity." It doesn't actually secure your site in any way or filter out anything, it just adds an additional step to the use of the site.
As for SMTP, yes, you can write programs to connect to port 25 on SMTP services and send data to those services. You may indeed be able to spoof emails in this manner. However, most services have other built-in checks and balances to prevent such spoofing.
TCP/IP supports 2^16 ports on a machine. A server program is said to listen on a specific port; other machines contact a server program at a machine using the port number and the name of the machine. It's like the address on a letter.
Some port numbers are "well known", which just means they're officially assigned for a particular service: port 80 is for web servers, port 25 for SMTP, port 25 for telnet, etc.
But any server can run on any port; it's just a matter of changing the code or the configuration. Sometimes you may way to run two separate web servers on one machine; one might listen on port 80, and the second one on some other port (8080 is a common choice for servers used during development.)
So the client can't meaningfully change the port to some random number: there has to be something listening on that port, on that machine, or it doesn't do anything.
There is no 'difference' between running a web server on any port number, from a purely technical perspective, as long as the client and the server both know which port to use. When the client connects to the server, it has to know the IP address as well as the port.
By convention, several ports are used by standard services. For example, port 25 is SMTP, port 80 is the http port, 22 is the ssh port, etc. Because of these conventions, ports less than 1024 are reserved by the operating systems and can only be opened by a root process.
Unless there is a specfiic reason, it is generally a good idea to stick with the standard port numbers. Advanced port scanners/ analysis tools will try all ports on a system, so there isn't much benefit to running a service on a non-standard port.
The port numbers are a way of multiplexing communications over IP links. This is commonly used to provide specific services on accepted port numbers. HTTP servers have been allocated port 80 for listening for incoming client connections, though this is not a lock - there is nothing stopping you constructing/configuring an HTTP server that listens on port 9001, or whatever. If you did use a non-standard port number for your server, then you would have to specifically instruct a browser to connect to that port, rather than defaulting to 80 as it normally does.
SMTP in port 25 using your own program - sure, you can do this. Any mail app is some developers' 'own program' .
Rgds,
Martin