Is it possible to connect to remote host with indy client and send data to the local server.
i try something like this and i don't receive anything:
Server:=TIdUDPServer.Create;
Server.OnUDPException:=UDPException;
Server.OnUDPRead:=UDPRead;
Server.Bindings.Add.Port:=10;
Server.Active:=true;
//Server is listening to local IP
Client:=TIdUDPClient.Create;
with Client do begin
Host:= '130.204.159.205'; //My IP
Port:=10;
Send('Hello');
end;
My goal is to create client/server applications that will communicate with UDP over internet
UDP is a connectionless transport. It does not guarantee data deliver like TCP does, especially over a large network like the Internet. If TIdUDPServer is not receiving data, then either the packets are not reaching the machine to begin with, or are being blocked before TIdDUPServer can see them. Use a packet sniffer, such as Wireshark, to verify that the packets are reaching the NIC(s) that TIdUDPServer is listening on. If they are not, then you have a networking issue. If they are, then you have an OS issue.
Yes it is possible. Let's bypass some questions and try this instead:
Host := '127.0.0.1'
If that doesn't work, check to see if your Windows Firewall allows your test application to connect to itself. (Turn off local software based firewalls and try it again.)
Related
I am developing an P2P application in Delphi XE5 with a PHP remote server as a tracker to make a list of the clients sockets. I am afraid that using UDP Hole Punching would fail at some point if client's NAT decides to close/block that random port it created with in the first message sent to the PHP remote server.
So I with to know How to make a more time persistent port configuration with NAT from the Client (which is written in Delphi). I do not want my user to need to know how to access a router and configure port forwarding himself.
Could I do that and use the server just to store the socket without the PHP-P-H and be sure that at least while the Delphi's application is running the port will remain opened?
If I do decide to use UDP hole punching from remote server, Will the NAT maintain the port opened to user's local PC if no other users connect to it directly (P2P) soon enough?
If I open that port with UDP, may I use TCP after?
Obs: Delphi XE5 to compile to Windows 32 and Android, so I need a non-Windows Only solution.
Microsoft has an API for working with NATs via uPNP, especially for assigning port mappings in particular. Look at the IUPnPNAT interface and its StaticPortMappingCollection property. Use IStaticPortMappingCollection.Add to assign ports in the NAT.
Of course, this only works with routers that have uPNP turned on. Not all routers support uPNP at all, or have uPNP enabled.
I have a IdTCPClient on my application and my firewall inform me about an outgoing connection to 224.0.0.252:5355. In the connection properties the used protocol is UDP.
I've searched for "224.0.0.252" and found that it's an IP multicast address (Link-local Multicast Name Resolution)
Q: Why IdTCPClient try to do that?
As its name suggests, TIdTCPClient only supports TCP not UDP.
UDP 224.0.0.252:5355 is used by Microsoft in modern Windows versions for Link Local Multicast Name Resolution (defined in RFC 4795) as part of their hostname-to-IP lookups when conventional DNS is not available.
When you ask TIdTCPClient to connect to a hostname, it asks the OS to resolve the hostname to an IP address before then connecting to it. Your Windows version is obviously utilizing LLMNR as part of that resolution, and your firewall is picking up on that. That is happening outside of Indy.
The connection to 224.0.0.252:5355 with protocol UDP is used by recent versions of Windows for Link Local Multicast Name Resolution (LLMNR) searching for local network computers.
If you have no local network you may disable LLMNR with a peculiar registry setting.
Create and execute the file "disable-LLMNR.reg" containing:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient]
"EnableMulticast"=dword:00000000
There is a lot of other answers related to this issue, however I believe this is specific.
I am using Delphi XE2 and Indy 10.5.8 and TIdUDPServer
In my local development network I have everything on the same network ip subrange and all connected to the very same Access Point (LinkSys)
I have Androids sendind UDP Broadcast to 255.255.255.255 to request the server ip address that is written in Delphi listening using TIdUDPServer on the port 44444.
The requests get there fine and I can answer back no problem. Works exactly as expected.
However I have noted that in some networks it does not work! It is always simple networks based on an access point, I am not sure but seems that where the problem happens the server PC is connect to the LAN port while the devices are using the wifi, all in the same access point.
Could be the case that the access points do not broadcast the UDP packet by the both LAN and wifi? I know that this kind of broadcast is very limited, but I have not found any information that tell me that in the same access point there is limitations like that.
Is there are ways to test, or workaround?
This solution needs to be strong enough to deal with the many AP out there.
EDIT: For those that want to get the source code for retrieving more information from the network including the broadcast ip as mentioned on the answer below follow this solution, it is all there.
http://www.code10.info/index.php?option=com_content&view=article&id=54:articleretrieve-network-adapter-information&catid=47:cat_coding_algorithms_network&Itemid=78
255.255.255.255 is not the best option for sending UDP broadcasts, and some routers/firewalls do block it unless configured otherwise. The better option is to use the NIC's actual subnet broadcast IP instead. For example, if a UDP socket is bound to local IP 192.168.0.1 with a subnet mask of 255.255.255.0, then the broadcast IP for that subnet is 192.168.0.255.
Most platforms have OS-specific APIs for retrieving a NIC's actual broadcast IP, such as getifaddrs() on POSIX systems, or at least for retrieving the NIC's subnet mask, such as GetAdaptersInfo() and GetAdaptersAddresses() on Windows, so you can calculate the broadcast IP manually.
Retrieving the local broadcast IP(s) may be added to Indy in a future version.
I spent the last two days reading each StackOverflow questions and answers (and googling of course) about Indy TCP and UDP protocol in order to decide which one should I use in my communication method between my User Application and my Windows Service.
From what I saw so far, UDP is the easiest and the only one I managed to work to receive broadcast messages from TidUDPClient (I did not testes the response back yet). And I also noticed that TCP is a bit more complicated with it's thread loop.
But since everywhere I am told UDP is not reliable, UDP is not reliable... I begin to wonder if it's not better to use TCP anyway.
My User Application will be running on many machines, and the Service will be running in one of them, sharing one IP with a Client, or in a dedicated machine, depending on my client's funds. So, should I really be worried about UDP data loss possibilities?
I need broadcast capabilities so my server advises all clients at once about Application updates, and of course, if my the Client Application does not know in which IP the Service/Server is, it will send a broadcast call to be told where the server is. Is that applicable to TCP?
The messages I am sending are requests for users access confirmation, users privileges, and application executable file updates, since the main application can't update itself.
Those messages are encrypted like below, and they might bet bigger sometimes.
e86c6234bf117b97d6d4a0c5c317bbc75a3282dfd34b95446fc6e26d46239327f2f1db352b2f796e95dccd9f99403adf5eda7ba8
I decided to use them both!
Simple use case:
In order to communicate with TCP prococol you have to establish a connection which you can have only if you know IP and Port on both ends.
If you do not have that information when you load your Application, then you use the UDP to Broadcast your IP address and your intention to find the/a Server. You may try about 5 times before you raise the user an error telling that you did not find the Server or that the Server is down.
Sending that message in UDP will (one time or other) reach the UDP ear of the Server, which will now know the IP from the lonely Client's IP and will now begin a proper connection via TCP to be read talk about the critical messages of the Application.
What do you think of that approach?
I am a newbie in network related aspects. I have few basic questions related to tcp/ip protocol and network
If a network switch (in a LAN network) between two PC's running Client and server (that are communicating through async. sockets) is powered down. Can the client and server will be notified that the socket connection is no longer active. Client and server are running on Win XP OS and are coded using C#.
Does network topology play a role in case of half open connection between socket client and socket server. For e.g. Will a disconnect status of either one or both be notified to other end and does it depend on network topology.
Thanks in advance.
A network element such as a router/hub/switch does not activly cause anything anything to happen on the TCP layer if it goes down. The operating system might notice that the physical layer is down and error out all sockets bound on that network card if it's a network element directly connected to the PCs that breaks - this will vary among operating systems/network cards and other things. Other than that, in order to detect that the connection has been severed, you'll have to send something and rely on the TCP timeout mechanisms to error out. This can be done implicittly by enabling TCP Keepalives on the connection.
A disconnect on one side will only be noticed if those messages reach the other side, if the network topology changes or sometinhg breaks in the middle of the connection in such a way that messages no longer reach the other end, a disconnect won't be noticed. (NAT gateways are a big source of problems such as this, they might time out a TCP connection they're tracking and you'll never know the connection is no longer valid unless you try to write something (or enable TCP keepalives) to the connection). Note that most networking APIs require that you Read from the connection to discovver that a the other end has closed the connection - assuming those "close" messages actually reach your side.