I'm try to build up the communication between a Windows desktop app and a group of Windows Store and/or Windows Store apps, using UDP multicast groups.
A communication module exists in all applications, but there is a problem: Desktop and Phone apps use classes from System.Net namespace, and the Store app uses classes from the Windows.Networking namespace.
It seems that the Store app doesn't receive any datagram, since the handler for the datagram received is never called (looking to Wireshark tracing, I found that datagrams for the specified multicast group and the specified port arrive from a machine to another, so there isn't a network problem).
It seems that classes from the two namespaces are incompatible, so I should use the same namespaces in all applications, but seems that the use of System.net in Windows Store apps is discouraged, or impossible. Also, it seems that the use of Windows.Networking in Windows Desktop apps is impossible.
Am I wrong? Any ideas?
You're wrong. A UDP datagram sent by any piece of software should be receivable by any other piece of software as long as both have functional IP stacks underneath. The Internet proves this every second.
Related
I am struggling to describe simply what the IP Application layer actually “is”. Some of my terminology may be “not quite right”, so I am happy to be corrected on my terminology as well. Is the application layer a “thing”? Or is it more “conceptual” than that? Is the Application layer on a particular node solely that collection of protocols (such as FTP, POP3, HTTP) that an application needs to adhere to if it is to successfully communicate with another remote application?
Conversely, if I write a program that does not strictly conform to an application protocol (say FTP) then there is nothing in the local “application layer” that will “stop” my attempt to communicate to the remote end using an invalid command? Whereas, if the remote end does conform to the application protocol, then it will reject or ignore my invalid communication attempt?
Or again, I could define my own protocol (not necessary as I guess all scenarios are already covered), and as long as my protocol was “robust and consistent” I could use it to communicate between two remote applications and everything would work? Or, is the Application layer a “thing” separate from the protocols?
The application layer is everything that's inside the application - that is, not within the IP stack (which covers network and transport layers).
If you want your application to communicate with an FTP server it needs to be able to speak FTP in order to work. If you write your own client-server protocol you can do whatever you want.
The network layers are there to make your life easier and to make applications compatible with each other. You can use or not use whatever you seem fit.
“An application needs to communicate with another application on a remote system. Any communication can be thought of as the exchange of messages and data between two partners. There are rules (protocols) that define for an application: what commands are available, the sequence that they can be exchanged between partners and any limitations on the data exchanged. For example: communication with an HTTP server uses commands: GET, POST and PUT (and others), whereas communication with an SMTP (mail) server uses: MAIL, RCPT and DATA, and similarly for other protocols. There are different protocols depending on the nature of the communication e.g. text message transfer, file transfer or video streaming. Any commands that are sent by either partner that do not obey those protocol rules is either: not delivered to, ignored or rejected by the remote application. Nothing prohibits application partners using their “own” communication protocol – for example Skype developed an uses its own protocol. However, there are standard protocols that handle most conceivable communication needs, so developing a new protocol may be unnecessary. If an application uses a “private” protocol its communication will be limited to remote applications that support the same private protocol. In addition to protocols, in a practical, real-world, system there are programming libraries (Programming interfaces) that enable the end-user application to request and participate in this communication. It is the end-user application’s responsibility to interact (send and receive data and parameters) with the (local programming) interface and the comms system’s responsibility to process those requests and deliver the data. In simplistic terms, one data transmission starts at one application and ends at another. However, IP provides other applications, such as DNS, that are used to set up connections, but the operation of these is not visible at the end-user application level. In summary, the collection of protocols and the programming interfaces available and used by an end-user application is the application layer on a system.”
I've been asked to implement VPN capabilities in an existing software project on an embedded system, in order to make the device available via network to an external server while avoiding trouble with firewalls (no need for encryption, just to make it accessible).
Unfortunately, the embedded system is based on a Cortex-M4 MCU, therefore Linux, which would allow for VPN nearly out of the box, is not an option. All I've got is an RTOS and a working LwIP stack.
I've used VPNs in the past. However, my network knowledge is rather limited concerning implementing VPNs, so I'm rather stumped. As I think, I'd use the current LwIP instance for building up the tunnel connection, and the application would use a second instance for the actual network communication, while the network interface of the second instance is a virtual one (like a tap device on linux), encapsulating its low level data and tranceiving it via the tunnel connection of the first LwIP instance.
Maybe this way I'd be able to create a custom solution for the problem, but the solution should conform to any standards (as the server will be any kind of sophisticated system).
So I wonder if anyone has been confronted with a task like this, and would appreciate any hint what to do, at least a direction where to look at.
Thanks in advance!
I have two applications that need to communicate with each other running on the same system.
I've been using the very strange practice of opening a TCP COM channel between the two applications for communication.
Is this practice frowned-upon in anyway? Is there any alternative (apart from using stdio, not possible due to other reasons).
Is there a restriction on maximum transfer rate and/or any latency involved (compared to piped stdio)?
I'm using the local (127.0.0.1) address for both server and client, will the connection be guaranteed to stay within the local machine itself or could it relay off the nearest router before coming back to itself and does the network card influence the properties of the connection at all?
I worked on a system a while ago with Java. and I was looking for the same question. I don't have much experience with it. But I ended up using tcp connections for communications for the following advantages:
1) The ability to put the different application in different servers in the future if needed to.
2) The applications are totaly independent. one application could crash without effecting the other one. If the working application then tries to connect it gets an error and you can handle that.
I saw this used in many other type of applications. So I went with it and it is working fine. But you have to be carefull and handle networks errors and IO errors and closing all open sockets after finishing with the connection. I was only closing the socket from the client end so I ended up with many CLOSE_WAIT ports in the server.
Regards,
It's pretty common to use TCP for inter-application communication.
Performance should not be an issue.
Sockets On Same Machine For Windows and Linux
You should consider security. What will happen if another user on the machine connects to the port, how will the application authenticate etc.
I have a somewhat basic understanding of network programming (and networking concepts in general) from taking a networking course in university a few years ago.
I remember being able to create a simple chat application, where the chat server is used as a central directory aware of which clients are currently online, but once a client knows another client it wants to chat with, the actual messages between them don't need to go through the server. I remember we could only test this over a bunch of LAN machines.
This C# chat program also has several comments mentioning that the program does not work over the internet: http://www.geekpedia.com/tutorial239_Csharp-Chat-Part-1---Building-the-Chat-Client.html
My question is why do these applications not work over the internet when "commercial" chat applications can. Surely, there is some way to make my computer accessible to the outer network even if its IP address is not valid outside the network of the ISP.
I see no problem with the linked-to code. The server doesn't even bind to a local address, which means it will listen for connections on all ip-addresses on the computer. There is however a comment for in the server article where the user changed the TcpListener object creation to bind to a specific address, which means clients only can connect to that specific address.
In the original server design, with using TcpListenet with only a port number, there should be nothing preventing its use on an Internet connected computer, unless there is a firewall blocking access.
Were you aware of networkComms.net and in particular the short chat example demonstrating the functionality here (It's less than 15 lines of code)? This was written specifically for people writing server-client apps in c# and given most of the problems you might come across will already have been solved and it might save you some time. This library is completely plug & play and has no issues working over the internet (as long as you can setup the necessary port forwarding where necessary).
Generally if both of your targets are behind NAT (so no true external ip addresses) and you are unable to configure port forwarding you need to look at 'TCP / UDP hole punching', quite an advanced technique.
Has anyone had any luck getting MSMQ multicast (PGM) to bind to a specific network interface using the MulticastBindIP registry setting?
MSMQ Multicast (PGM) always seems to bind to the first interface listed by ipconfig. In my case, I have VMware installed, so I have two virtual network interfaces (VMnet8 and VMnet1) as well as my network card. It isn't useful to have MSMQ send PGM packets to the VMware virtual interfaces.
I have attempted to use the MulticastBindIP registry setting (of course, restarting MSMQ after the change), but this does not seem to make any difference. For example, the IP address of my "Local Area Connection" is 172.18.224.245, so I set the following registry key value:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Parameters]
"MulticastBindIP"=dword:ac12e0f5
The DWORD is stored with most significant bytes first. However, using wireshark, I can see that the PGM packets are not getting sent to this interface (but still sent to the first interface listed by ipconfig).
The documentation could be wrong, so I also tried variations such as: least significant bytes first and even using a (dot-delimited IPv4-style) string value. Nothing seems to make any difference. The only way I can get MSMQ multicast to bind to the correct interface is to disable all virtual interfaces. This isn't a workable solution.
If anyone is interested, "MulticastBindIP was introduced for Windows 2003 Server and not back-ported to Windows XP". Thanks to John Breakwell's help. See this Microsoft newsgroup discussion for more details.
The only solution I've found on Windows XP is to disable all interfaces except the "Local Area Connection". When you re-start the MSMQ windows service it will bind to the correct network interface (because it's the only one available). I suspect it's not that common to have multiple network cards in a machine running WinXP, but it is common to have VMware or VirtualBox virtual interfaces that expose this issue with MSMQ binding.
FYI, For more recent operating systems, where the MulticastBindIP registry setting is supported, there is some debate on whether the value is a DWORD or REG_SZ.