I'm trying to create a Unity Program that will read from a socket that's sending UDP packets, and create in game changes accordingly. I was able to process data great with the UDPClient class, but then when I switched platform to Windows (I need it to be this because it's running on Hololens), the UDPClient was not recognized and I had to switch to the Windows.Networking API. I've found some examples online on people accepting UDP in Unity like these:
https://forums.hololens.com/discussion/578/hololens-udp-server
https://forums.hololens.com/discussion/7980/udp-communication-solved#latest
But even when I try them unedited (with the exception of ports and ip addresses), I get nothing when testing with my Packet Sender app. Can anyone point me in the right direction? I'm a little confused by these examples as they don't use the infinite loop I'm used to using in sockets, and instead use some sort of weird event handling.
UWP apps are not allowed to receive UDP packets from local host. You need to run your packet sender app on another machine. See this:
See this: UWP app doesn't receive UDP Datagram from a .NET desktop app on localhost
Related
What I want to implement is UWP-based programs and other C# programs are trying to communicate with Socket on one PC (Windows 10 Pro).
I have tried to make UDP communication module using DatagramSocket class and TCP communication module using StreamSocket class (https://msdn.microsoft.com/ko-kr/windows/uwp/networking/sockets) and it seems that module is not working properly.
In the Windows UWP example program and some developer forums, I saw a statement that it is impossible that socket communication between other programs on the same device.
I am wondering if it was the right I understood.
Also, if it is right, Would you recommend other ways to solve this problem?
I saw a statement that it is impossible that socket communication between other programs on the same device
It is right. According to the note of DatagramSocket official sample:
Network communications using an IP loopback address cannot normally be used for interprocess communication between a Universal Windows Platform (UWP) app and a different process (a different UWP app or a desktop app) because this is restricted by network isolation.
We cannot communicate a uwp app with other apps in a same machine.
Also, if it is right, Would you recommend other ways to solve this problem?
By testing on my side, if you use a c# console project as server and a uwp app as client, they can communicate successfully both with StreamSocket and DatagGramSocket. But following special steps need to pay attention to let it work.
Please ensure the Internet(Client&Server) and Private Internet(Client&Server) capabilities are enabled.
Run the server side as administrator.
Allow the network access promoted by windows when you run the server.
I wrote a demo which contains server side and client side of UDP and TCP. You can download here for testing.
And the results.
Although this can work, I recommend you to not use except for developing purpose.
I'm trying to write a simple UWP IoT App that is to run on Windows 10 IoT Core on a Raspberry Pi.
The App need to test if another device is currently alive on the local network. All the Apps knows about this other device is its ip address.
I see from other SO questions that Ping is not supporten because ICMP is not supported on WinRT. I assume this also the case on UWP?
I guess I could create a socket and try an connect to for example port 80 and unless a time-out error is received then that means the device is available. However that "hack" seems a bit messy and I'm not sure that it would be solid enough to rely on.
Any other ideas for some C# UWP code that can be used for testing that a device is available and alive on a local network based on its ip address?
You are correct, ICMP is still not supported on UWP. But you could use this instead: https://github.com/christophwille/winrt-vasily (it's kind-of what you wanted to do, but already done)
I'm working on multiplayer game on w7.
I use UdpAnySourceMulticastChannel class from RockPaperScissor example http://msdn.microsoft.com/en-us/library/ff431744%28v=vs.92%29.aspx
The problem appears when I want to play device-to-device which simply don't even want talk to each other (Send working, SendTo not) - in fact, this occurs also on sample.
devices: LG E900 & HTC Trophy
//----
Edit (after KooKiz anserw - sorry, I should wrote it at the start):
Specify a bit:
Both devices are connected to same router and see messages send to multicast group (game lobby working)
Sample application also aren't working (see each other - game lobby working)
both applications working device-emulator
UDP multicast usually doesn't work over internet. It works with the emulator because they are using the local network. It should also work if you connect every device to the same wifi router.
More information: UDP Multicast over the internet?
If you want the devices to communicate outside of the local network, you'll have to put a server in-between to forward the data to each device.
The problem was in router - when I connected to other it works, if anyone know why exactly that works with emulator-device but not device-device can say it and consider as 'correct' anserw (I'll mark that)
I am working an application in windows phone 7 that must detect the devices connected to particular port no or network. I have desktop application that is implemented in c++ that uses UDP broadcast. I read some articles and know windows phone 7 doesn't support UDP broadcasting. I have tried UDP multicasting in WP7 but due to desktop application have implemented in UDP broadcast, I am not able to do that.
Help me Guys...........
You can use socket.ConnectAsync with e.Buffer containing the message you want to broadcast. In this case, the message will be sent automatically when connection is established. More information about this trick you can read here
You could send a broadcast packet through just SendToAsync method by using limited broadcast IP, not local broadcast IP(such as 255.255.255.255) This means, if your NIC device is in 192.168.0.x IP range, you should shoot a packet to 192.168.0.255. (this IP might be vary on your netmask setting)
However, it works.
Additionally, response back is also allowed but FOR 5 SECONDS ONLY. Your host received a UDP packet from Windows Phone 7.1 device, the host should response back to the port that UDP packet came from, IN 5 SECONDS. Unless, Windows Phone will close the port then, and it has to be gone.
It's very tricky, weird, and ununderstandable(like this word) way.
but it works as far I know.
Recently I have started working on a program that will monitor the packets of one of my open-source programs in an attempt to learn more about programming and networking. Also, I want to add additional functionality to the program without editing the source, like an external control panel.
(I used WPE Pro to filter packets in case you'r wondering, WireShark is too much hassle for such a simple task.) One thing bothers me though, the Socket ID.
I know what it is, and I've asked a question about it before, but I cant figure out how to use it/assign one/intercept one.
Without the right socket ID, my program wont be able to do anything, so my question is if it's possible to find out what Socket ID a socket is using, once you capture the packet?
If not, are there any other ways of doing? -or possible other languages like Visual Basic?
Thank you for your time.
If, by socket ID, you mean the return value of a successful call to socket() function, I don't think there's a way.
The closest thing you can obtain is the process ID because, as you may already know, each IP packet has a destination that's described by the tuple (IP address, port) and inside a system only one socket can be successfully bound to that tuple. Utilities like TCPView are able to map an IP tuple to a process, so a way does exist if that information is enough for you.
If that's not the case, I'm not aware of any method to retrieve the socket ID you need if the target application is not collaborative.
This library: SharpPcap promises doing capturing, injecting, analyzing and building packets using any .NET language such as C# and VB.NET (more info).
It is the library used by Wireshark and it is for sure that it can capture and analyze.
socket() returns a file descriptor if this is what you are referring to as a socket ID then the ways to get this without the process's collaboration on windows are limited. FWIW on linux open FDs are enumerated in the proc filesystem.
That being said, the only thing you would be able to do with the fd is send additional information from the socket. You could also read from the fd, but any data read in this way would not be sent to the application that owns the socket. Without some coordination, that would probably not be what you desire as you would just get bits and pieces of data.
If just want to be able to listen in on the traffic in your program, then something like packet filtering should be sufficient so I assume you actually want to be able to be like a man in the middle for it.
If this is the case, then the best thing to do would actually be to set your application up as a proxy for your other service.
By this I mean, write a program that opens a listening port and accepts connections when a connection is initiated, it should immediately open its own connection to a pre-configured IP:port combination and begin forwarding traffic. Once this is written it's a simple matter to inspect the traffic before forwarding and possibly modify it.
If your program is a server, run it on a non-standard port, configure this application to open the server's normal port and then forward connections to the non-standard port you set up on localhost.
If your program is a client, simply point the interceptor application at the server and choose a random listen port on your box. Then configure the client to connect to this listen port as though it were the server.
This should work for pretty much anything. The only caveat is if the traffic is encrypted you will (obviously) not be able to inspect/modify it. This is effectively the same as placing your application behind a NAT.