I have an application where I have potentially many processes must send a message to one process. I figured the most expedient way to do this would be to just send a UDP datagram.
When opening a socket, I need to specify which port to listen to. As I just want to fire and forget the UDP datagram, I'd like to just have the OS pick an available port. I'd rather not have to hunt for one, especially as many instances of my process may be running. Is there a way I can tell the OS to just pick an available port (or better yet, not even open a listening socket) to fire and forget my UDP datagram?
Yes. Specify 0 as the port. The OS will pick an available port for you.
Answering the "Problem" rather than the "Question"
If all the processes are operating on the same PC, you might want to look into shared files or some other means of communications other than a networking stack.
I'd suggest you explore the options in Boost's Interprocess library
http://www.boost.org/doc/libs/1_37_0/doc/html/interprocess.html
Quick guide here:
http://www.boost.org/doc/libs/1_37_0/doc/html/interprocess/quick_guide.html
Specifically, I suggest you use a named pipe or shared memory between your processes.
Related
I have a configuration where 3 applications run on 3 different Virtual Machine's and they must communicate via DDS i.e. RTPS protocol.
The configuration is as follows :
ROS2 based ADAS functions
Simulation Tool
Python/Tensorflow based machine learning functions
All 3 need to be on different VMs.
It is not possible at our end to allow multicasting for the MS AZURE VM and our network.
Here are some questions :
Is it still possible to communicate via DDS ?
If yes, through UNICAST i.e. peer to peer connection ?
Is using DDS communication beneficial in this case if i already have the option of basic UDP socket programming ?
Could you think of any restrictions/ further problems in using DDS for such a configuration ?
Is it still possible to communicate via DDS ?
Yes, it is. Out of the box, DDS Participants only use multicast for discovering other DDS Participants, at startup. This discovery mechanism can be configured in several ways. For a an explanation on how to achieve that, see this RTI Community Knowledge Base article: Configure RTI Connext DDS to not use Multicast.
If yes, through UNICAST i.e. peer to peer connection ?
Yes, with the no-multicast setup, all communications are done over UDP unicast, peer to peer, connectionless.
Is using DDS communication beneficial in this case if i already have the option of basic UDP socket programming ?
Not being able to use multicast does not remove any of the DDS advantages when comparing it to UDP. When using DDS, the transport/discovery configuration is typically invisible to the application and all Publish/Subscribe concepts remain unchanged.
If you are asking about the advantages of using DDS versus UDP, I think that warrants a new question on itself. The answer will be quite extensive :-)
Could you think of any restrictions/ further problems in using DDS for such a configuration ?
With this configuration, your configuration settings will be dependent on the network that you are running on. This means that migration to a different network might need reconfiguration, for example providing different host names or IP addresses. This is inconvenient, but not hard.
Since your environment is restricting the use of multicast, I would not be surprised if there are more restrictions that you have not mentioned or discovered. For example, do you know anything about firewalls or network bandwidth restrictions? Again, DDS can be configured to deal with such things, but you need to be aware of them first.
I'm almost completely done with and iOS client for my REST service. The only thing I'm missing is the ability for the client to listen on the network for a UDP broadcast that receives the host display name and base URL for uploads. There could be multiple servers on the network broadcasting and waiting for uploads.
Asynchronous is preferred. The servers will be displayed to the user as the device discovers them and I want the user to be able to select a server at any point in time.
The broadcaster is sending to 255.255.255.255 and does not expect any data back.
I am a beginner in objective c so something simple and easy to use is best.
I recommend looking at CocoaAsyncSocket. It can handle UDP sockets well. I haven't tried listening to a broadcast with it, but it's probably your best bet.
I have following scenario:
Server should be Daemon.
Other Apps should be clients.
Many clients should communicate with server to get their task done by server at a time.
These tasks are such as copyfile, deletefile etc.
My solution:
Server has 5 worker threads each containing named pipe. Each pipe's availability status is kept in Shared memory structure. When client wants to communicate with server, it checks which pipe is available from shared memory then opens that pipe & sends its message on that pipe, respective worker thread of server servers this client request. That worker thread sends request status (Success/failure) on that pipe so that client will become aware of last operation status.
As far as I know, pipes on Mac os x are unidirectional & they lack capability of creating unlimited instances like Windows.
What mechanism could be best suited for such kind of communication?
Thanks,
Vaibhav.
As far as I know, pipes on Mac os x are unidirectional & they lack capability of creating unlimited instances like Windows.
Pipes are one directional, but Unix sockets are not. This is probably what you are after if you want to directly port your code to OS X.
However, there are probably better ways to do what you want to do, including stuff like Distributed Objects which I admit I have never used. Even if you stick with a socket interface, I think one socket would be easier with a thread monitoring the socket and handing off work to worker threads as it arrives, using listen and accept. Better still, have an NSOperationQueue or a dispatch queue to put the work on, then the OS will handle the task of optimising the thread count.
"Because winpcap sends and receives data independent of host protocol such as TCP/IP, which means winpcap can't stop, filter and take control of other applications on the same machine control, it can only monitor them simply, so it can't provide support for similar network flow control, the quality of service, personal firewall and so on."
In this passage, what "winpcap can't stop, filter and take control of other applications on the same machine control" means?
It means that if some program on your machine is sending and receiving packets, the path those packets take through the operating system does not, and cannot, go through WinPcap; all WinPcap can do is listen to see copies of the packets sent and received by the machine.
This means that if you want to, for example, implement a firewall program to prevent other programs from connecting to particular addresses or ports or receiving connections from particular addresses or ports, or to modify packets sent by other programs before they get put onto the network or modify packets received from the network before they get passed to other programs, or do something else "active", you cannot use WinPcap.
WinPcap uses mechanisms in Windows that are intended to support programs such as packet sniffers, so that limitation is inherent in WinPcap; a library to support writing firewalls and the like would have to use different mechanisms in Windows (and those mechanisms might not support programs such as packet sniffers).
Can anyone tell be where to use the UDP protocol except live streaming of music/video? What are default usecases for UDP?
UDP is also good for broadcast, such as service discovery - finding that newly plugged in printer.
Also of note is that broadcast is anonymous, you don't need to specify target hosts, as such it can form the foundation of a convenient plug-and-play or high-availability network.
UDP is stateless and is good for applications that have large numbers of clients connecting to a server such as time servers or DNS. The fact that no connection has to established and maintained reduces the memory required by the server. There is no handshaking involved and so this reduces the traffic on the network. On the downside, if the information transferred requires multiple packets there is no transmission control to ensure that all packets arrive and in the correct order - but in games packets lost are probably better than late or disordered.
Anything else where you need performance but can survive if a packet gets lost along the way. Multiplayer games come to mind, for example.
A very common use case is DNS, since the overhead of creating a TCP connection would by far outweight the actual payload.
Additional use cases are NTP (network time service) and most video games.
I use UDP to add chat capabilities to our applications. No need to create a server. It is also useful to dispatch events to all users of our applications.