I have two my own applications on C++ and Java: server and client. It both in one LAN and can transfer data via specified port. I want to make it possible, that client can find IP of server. But how to?
Enumeration of all possible IP with address mask - bad idea, it will take a lot of time. May be exists some way, where I can send broadcast to lan from client and receive it in server? Or another way... I can't find information about this, but I think that is possible, because I see it in MyPhoneExplorer on android, for example.
Why not using UDP broadcast?
the client can UDP broadcast "I am at x.x.x.x", and the server can answer (in UDP) to the client, "I am at y.y.y.y".
maybe you can use the Broadcast Address to find your server.
Related
I have a server and a few clients, software-wise, and I want the client to figure out the IP address of the server without actually referring to a specific database.
I had a misconception about UDP up until now that UDP only used the Port as a common identifier between servers and clients, but I was wrong apparently.
Requirement:
I want my server to broadcast a message to ALL devices on the network, once every 5 seconds or so.
That message will contain the IP of the server.
Software using such technique already:
A photo transfering app for iOS, called "Photo Transfer App" is really easy to use because it basically tells you to open the app on your Mac and on your iPhone, and then you press "Discover", and BAM! your devices have found each other.
But how?
How can my requirement be achieved?
EDIT
I googled a bit. Could server host on 255.255.255.255and clients connect to that address solve my problem?
According to this Wikipedia article, 255.255.255.255 is used for broadcasting.
Can someone confirm?
If you will use broadcast address (255.255.255.255) or network broadcast (like 192.168.1.255 for network 192.168.1.xxx or in the prefix notation 192.168.1.0/24). You will get essential limitation: your broadcast will NEVER leave that network. So all host inside the LAN will see your broadcast message but nobody else.
Multicast as mentioned by null is better because it can leave your network and pass through the IP routers. But this is feasible only by special network settings on that routers (and require multicast routing capability on that routers).
Another technology without such limitation can be use is dynamic DNS (server will register itself via DNS).
Multicast would be better than broadcast. See also: Bonjour, multicast DNS & SSDP.
More information on Bonjour is available here.
Good Day,
I basically have a laptop connected to the internet with a fixed IP Address. I need to have a way for a server possibly though a PHP script, send data/string to the laptop and it is able to receive it.
Now, if I was within a local network, i could do that. But what if I wanted to send from an external network? Do devices have a particular address that I can access from any internet connection?
Do devices have a particular address that I can access from any
internet connection?
No, it does not, unless you do use external IP for your laptop (doubtfully).
The easiest and fastest solution I could think of is to do the other way round: open TCP or UDP socket on your server and use laptop to connect and request data from the server. Of course, it is not suitable for all scenarios, but in many cases it works. Write more information (what is the purpose of this? What are the requirements and limitations?) so more specific answer may be provided.
OK, to make things easier to explain, let's say:
- Your router's public IP address is 10.10.10.10
- Your laptop's private IP address is 192.168.0.1
- You want to communicate via port 80 (since you mentioned PHP)
What you need to do is configure your router so that it forwards packets destined to 10.10.10.10:80 to 192.168.0.1:80. This is the simplest form of NAT.
Then from anywhere else with an Internet connection, you can send packets to your laptop by sending packets to 10.10.10.10:80.
What I need is quite the same asked here, I don't understand the answer too well, because of my knowledge, so maybe someone could help me.
What I'd like to do is using the connected user's IP address (Client IP) to make the server-side HttpWebRequest, so I would grab the user's IP and make the call with it.
What I'd like to obtain is that every connected user makes HttpWebRequests with their IP.
Is it possible?
If it is, how should I edit that code to do this?
Thanks.
This is impossible. My answer to the other question was about selecting which IP Address (read: network adapter) to use for a request. However, you cannot invent IP Addresses out of thin air, nor use IP Addresses that are not yours (in a physical, attached-to-this-computer sense).
Now, technically, using Raw Sockets, you can spoof another IP Address in your packets. However, the problem with that is that the return traffic will go to the IP Address you specify, not the one you actually have!
So, my advice is to not pursue this line of thought any further, and find another way to do whatever it is that you are trying to do.
You may only make outbound connections from your server using an IP that is assigned to the server. If you tried to use a client's IP, it would fail.
Even if it did not fail, it would be a form of spoofing and would fail pretty qucikly anyway- the handshake that occurs using tcpip would case the remote connection to send an acknowledge packet back to the source ip (in your case, the client ip) which would result in an error.
If you are using UDP, it actually is possible to do this, but that is a different subject.
I've noticed recently that I don't have to forward ports for mmorpg's that I play.
I'm thinking about working on a game that people can play online and had a question.
Why is this the case given its a two way socket connection that is constantly sending data back and forth? Doesn't their server need to get through my firewall in order to connect to me?
TCP crash lesson: TCP is a two-way protocol. The challenge is that at least one host needs to initiate. Since within an MMORPG, your own computer is never acting as a server, nobody has to connect to it. All the information about game state is passed through the company's public facing servers that have public facing IP addresses (and hey, maybe they actually use port forwarding there, just to confuse my explanation... but you never have to see their pretty network internals, proxies, and other wizardry.).
Anyway, when you connect to Stackoverflow, you're making one outbound connection that requests data from the server, and then over that same connection you're receiving it back. Same exact scenario, only with a webserver instead of a game.
UPnP allows you to tackle many routers. There's also NAT Punch-Through if you have access to a third party that isn't behind a router.
Either way, port forwarding is only necessary if you wish to act as a server (or the sender in a P2P relationship). A client does not need to forward ports.
You don't need to forward ports to access the web either, despite data coming in as well.
When you make an outgoing TCP connection, your NAT router puts the connection in a table, so that when data comes in, it knows what machine in your LAN to send the packet to.
Everyone mentions TCP, but NAT works for UDP as well: The first outgoing UDP packet associates that source port with the internal IP address, and your NAT device will forward incoming traffic to that port to the correct host on the internal network.
In other words, if your computer requests the connection (outbound) first, the router opens up the port automatically, on the assumption that you're going to want data back. But if you want remote users to connect to your computer without your computer requesting it, the router would normally drop the packets since it wouldn't know where to send them (they were unsolicited). So instead, you need to tell the router to deliver any unsolicited packets at port N to your computer.
Sorry to add another answer so late, and I know one was already accepted, but I personally found the other answers to be more confusing than this simple explanation.
We meet a testing scenario which needs to tamper with source IP address of a Http request to simulate clients coming from different countries. Do you know any tool help on this?
Last but not least, our web site is built with ASP.NET.
Thanks.
In a test environment it usually isn't difficult. First read this SO question about virtual network interfaces.
If the server and client are on the same machine, all you have to do is figure out how to get your client software to bind to your virtual interface.
wget for instance has the --bind-address option to specify which local address to bind to. Web browsers are a bit more difficult to do this with; you may need to just run it in a VM.
If your server and client are on the same LAN, you just need to configure your router with some static routes to your client machine. In this case you probably don't need a virtual network interface, just set a static IP for your client machine; as long as the gateway is set up correctly it should be able to send packets to the server, and as long as the route is set up correctly the replies should find their way back to the client.
If the client and server are separated by an internet, it's rather more difficult. One option is to set up a network tunnel endpoint on the server and tunnel it to the client machine, which "knows" that it has the virtual network interface.
As noted in answers to the ServerFault question "Are IP addresses trivial to forge", you cannot easily forge source addresses in a protocol that required two way communication (e.g. TCP). Note that this "two way communication" is required at the packet level. You cannot just say "no problem, I want to send requests and ignore HTTP responses." To establish a TCP session, you need to receive data. Your best bet is to use a proxy server.
I am unsure if the IP standard allows for this, but if you are working in a Lab environment, where you don't need internet connectivity during the test, I can see it working under following circumstances:
Basically, I would set the server's network interface to use netmask 0.0.0.0 and flush the rest of the routing table.
Then you could configure a client machine to take on any IP address as long as you use netmask 0.0.0.0. And two-way communication should be possible.
Server[1.2.3.4/0] <---> Client[x.x.x.x/0]
But please bear with me. I haven't tested this, so I could be wrong :-)
If you have access to your infrastructure, you can add an interface off the router and then place a static route on the router to that network.
Server-----Router----Internet
/
Test_PC----/
Alternatively you can look into PBR (Policy Based Routing) and on the routers you can flag source packets and change the source on the fly, so your server will think they are coming from where you'd like them to come from.
Server-------------Router_with_PBR-------------Internet----- PC
SCR:4.2.2.2 Change SCR:6.6.6.6 to 4.2.2.2 6.6.6.6
But you have to ask yourself why do you want to see when packets come from different countries. Some countries have massive proxy servers that filter access ( "Great Firewall of China"), so the above tests will not prove much.
Your best bet then is using proxy servers or if your looking for a long term solution then setup a server (virtual is great for this) and use RDP for testing. I'm sure you can rent a virtual server somewhere for a month or two.
That's not possible. Because when you forge the ip address, the response is never going to come back, which is required for http.
The best way is to use proxies. See also this question on serverfault.
If you change your source IP address, that means no traffic from your web server will be able to reach back to the client.
You might be able to use some kind of proxy and/or address translation filter to do the remapping while still allowing two-way communication.