I want to create a Console Application in VB that broadcasts to all IPs on Local Area Network his own Ip.
So a Timer that broadcasts the IP of the server every second. Every client that connects, receives the IP of the Server.
Then, a client logs in to the Application and sends 2 strings to the Servers IP:
Username
Password
The server checks the validity of the 2 strings, and either allows or restricts access to the Server.
How should I proceed?
I have found TcpClient and TcpListener, but I am unable to broadcast an IP to 255.255.255.255...
Mainly, what I want to achieve, is broadcast (255.255.255.255) my Local Ip (192.168.1.1), so I would broadcast the String "192.168.1.1"
You should take a look at the UDP classes instead of the TCP classes. UDP will allow you to broadcast small messages on your LAN. One the IP address is received, then you can use TCP to connect to the server.
Related
I have multiple TCP Socket servers waiting for connection (one per machine). On another machine is a client which connects to these servers in order to perform some configuration.
Is there a way for me to see which hosts are on the network waiting for connection (preferably without knowing their IPs). Is there some way for the host to 'announce' that it is there and waiting for a connection?
All clients/hosts are on the same subnet.
Each server could certainly broadcast/multicast its listening info to the subnet at regular intervals. But that is a lot of redundant traffic.
An alternative is to have the client broadcast a request to the subnet that the servers all listen for, and then they can reply directly to the client with their listening info.
Otherwise, the client could just calculate the available IPs for the subnet and then attempt a connection to each IP/port to see which ones succeed or fail (typical port scanning scenario).
I wish to understand what generates the ICE candidates in a local webRTC application that does not use a STUN server.
Without a STUN server configured, the only candidates you might get from onicecandidate are host candidates, based on your system's IP address in its local network. The browser running on your system already knows this IP, and does not need ask a STUN server for it.
A STUN server is only needed to learn what IP addresses a system might be contactable on from outside a NAT. A STUN server acts as a mirror that sends back the IP it sees from packets sent through the NAT.
I have created a simple tcp client-server application in vb.net. Everything works fine when i set local host (127.0.0.1) as the ip address. I wish to make a connection to a remote machine (keeping client at my machine and server on the other - or vice versa).
EDIT:
ok, the code of interest is as follows:
the server:
Dim server As TcpListener = New TcpListener(IPAddress.Any, port)
the client:
Dim theip As IPAddress = IPAddress.Parse(TextBox1.Text)
client = New TcpClient(theip.ToString, port)
Now, what should i enter in "TextBox1.Text" if i have my client on a remote machine (connected over internet) and server at a different computer (whose external IP address is known)?
Can i enter the external IP address of the machine running the server directly in the text box? Also, do i need to take care of things like "port forwarding" / "let firewall allow the connection" and all? If yes, can you please guide me or link a tutorial so that my application does this automatically or is there an alternative approach to achieve this and so that port forward is not required? Thanks a lot!
You say the other machine has an external ip address. This implies it also has a local ip address; ie it is behind a NAT firewall or similar. In this case, you will have to configure the firewall to allow communication to take place, eg by setting up port forwarding.
Applications such as MSN Messenger, VOIP clients etc have elaborate mechanisms to negotiate this automatically, but they're often not very successful.
I am working on a C++ server/.NET client applications couple in which my server (which runs the c++ on linux) broadcasts a message to show it's alive to the whole network and my .NET program listens for packets and parses to get the uptime of the server.
As I have read, to send a regular UDP broadcast to the broadcast address, I simply have to send a packet to 192.168.0.255 (in my case 192.168.2.255) or 255.255.255.255. Is this right? Can I use the same port address? Are there any other necessities?
I understand the fact that if my .NET program listens on that particular address it is possible to receive packets from other applications than my C++ server program. Is there any method of "signing" the packet on the C++ server-side in order for my .NET program to read the header of the packet and see that it is (almost) the one I am looking for?
Regardless of the language you are using, here is my answer:
Regarding the broadcast IP addresses, both addresses are broadcast addresses but the limited broadcast address (which is 255.255.255.255) won't be forwarded by routers. It is better to use the subnet-directed broadcast address (192.168.2.255).
In order to send/receive a broadcast address, you need to define your broadcast address (broadcast IP address and port number). For example: 192.168.2.255 and port number 3000. The client applications (the senders) MUST enable SO_BROADCAST socket option as follows:
int enabled = 1;
setsockopt(sockfd, SOL_SOCKET, SO_BROADCAST, &enabled, sizeof(enabled));
where sockfd is the socket descriptor.
The server application will listen on a specific port number (port 3000). Normally, the server will respond to each request using unicast message.
There will be no conflict as long as no application is listening on the same port number. Your server will not run if another application is listening on the same port unless you enabled SO_REUSEADDRESS socket option. However, if there is a conflict, then your signiture is depending on your protocol (message format). So, check the message format and reject the message if it does not follow the message format defined by your application protocol.
For client applications, the received packet is unicast (unless you have another design). So, no conflict at this side.
You also have to enable the SO_BROADCAST socket option in C++ to send broadcast traffic, or you'll get a permission denied error:
int broadcastPermission = 1;
setsockopt(socketDescriptor, SOL_SOCKET, SO_BROADCAST, (void*)&broadcastPermission, sizeof(broadcastPermission))
If your .NET program listens for broadcast traffic, it will receive any and all broadcast traffic on the network sent on that port, including traffic not sent by your server. You could put a "marker" in the payload of the broadcast messages sent by your server. This way, your .NET program could distinguish which ones it cares about.
Beyond that, I would recommend using multicast instead of broadcast. Broadcast traffic is usually restricted to hosts on the same subnet. In layman's terms, if you have a router in your network, a host on side A of the router will not see broadcast traffic sent by a host on side B (and vice versa) because the router "blocks" it. Routers will almost always forward multicast traffic if a host has joined the multicast group.
Is it not possible to specify the local client port used for server calls via NetTcpBinding?
NetPeerTcpBinding support this - I find it hard to believe there's no way to specify the local port (and IP Address for that matter) on clients.
I need to be able to use port sharing and I can't do this if I don't know what port the client is listening on. I won't be able to share the port (and IP) with another client so it can connect.
The only work-around I found is something like this:
Client A opens a connection to Server
Server logs the IP and Port of Client A
Server shares this info. with
Client B
Client B should be able to
connect to Client A on specified IP
and Port (in theory)
This is known as TCP/IP NAT hole punching I believe. Anyone with experience in this?
You probably don't understand the communication pattern with NetTcpBinding. It works this way:
The client opens connection to the server
Two-way communication: The client calls the server and gets the response over the same connection.
Duplex communication: The client calls the server. The server stores reference to the channel somewhere (you must implement this). Once the server wants to notify client about anything it takes stored channel and calls the client on the connection established by the client during its first call.
The server never opens connection to the client. The client doesn't expose any address with port for incomming communication. If you want to do that you must implement service on the client in the same way you did it on the server and you must manully send the address and port to the service exposed by the server.
The difference with NetPeerTcpBinding is that there is no real server and any client must be able to get incomming request. NetTcpBinding is for client-server scenarios where the server is the only peer able to process incomming requests. Because of that only the server needs to define an address and a port.