I'm creating my own server using some protocols : TCP-PULL ok, TCP-PUSH ok, UDP-PULL ok (but I can't serve two clients at the same time!), UDP-PUSH ok (same problem).
Now, I need to create my the last protocol : Multicast-PUSH, but I can't understand how it works and I really don't know how to code it in C++. I've read about join a group and that in multicast there's no connection, so bytes are sent even if anyone is connected.
I'm coding in C++, using MFC libraries and CSockets.
Could please someone help?
Thank's!!
Consider an example where one system needs to send the same information to multiple systems. How best to accomplish this? The obvious approach is to have a socket "connection" for each target system. When data is ready to be sent, the sender iterates over each "connection," transmitting the data to the target system. This iteration process has to occur every time a message is sent, and it has to be robust such that if a transmission fails for one system, it doesn't fail for the remaining systems. But the problem is really worse than that because typically all the systems in a multicast exchange which to transmit data. This means that each system has to have a "connection" to each and every system wishing to participate.
This is where multicast comes in. In multicast, the sender sends data once to a specialized IP address and port called the multicast group. From there the network equipment, e.g., routers, take care of forwarding the data to the other systems in the multicast group. To achieve this, all systems wishing to participate in the multicast exchange have to "join" the multicast group, which happens during socket initialization and is used to simply notify the network equipment that the system wishes to participate in the multicast exchange. There is a special range of IPv4 addresses used for multicast - 224.0.0.0 to 239.255.255.255. You must use an IP address within this range and a port number of your choosing in order for multicast to work correctly.
Check out the Multicast Wrapper Class at CodeProject for an example of how to do this in MFC.
Related
[Similar Questions]:
Problems using UDP sockets bound to the same port on Windows
Handling multiple UDP sockets listening on the same endpoint
None of which ever got resolved.
[Situation]:
On Microsoft Windows, I bind two UDP server sockets in the same process. This particular (not to say peculiar) operating system supports only SO_REUSEADDR, it does not support SO_REUSEPORT; and on top of that, SO_REUSEADDR acts like SO_REUSEPORT.
So, considering the above, I am left with binding socket A to 0.0.0.0:1234 and socket B to say 192.168.1.1:1234; if I'm to reuse the same port on the same machine.
Namely, I cannot bind both to the same IP address, since Microsoft Windows would not agree with that; since yet again, it does not support two sockets to be bound to exactly the same tuple of {SRC_ADDR,DST_ADDR, SRC_PORT,DST_PORT,PROTOCOL} even when SO_REUSEADDR is used on BOTH sockets.
So, I'm forced to bind to two distinct addresses, if I'm to use the same port on the same machine. Even though 0.0.0.0 represents any address, but in any case Microsoft Windows agrees, and binds the two sockets in such a configuration, without any error.
The binding operations, in such a configuration for the two UDP sockets, do succeed.
Problem:
Now, I'm having trouble getting these sockets to receive data as expected. Namely, I expect the two sockets to receive data. In reality, only the socket which got bound first receives data.
Any ideas?
Is it that the data is always received by the socket best matching the destination? If you wonder why I'm playing that way, it's because I'm trying to multiplex two libraries with two protocols over the same port, with the least amount of modifications.
If you want two ports are received same udp packet you should set option/flag broadcast for transmit socket.
Something like:
socket_.set_option(boost::asio::socket_base::broadcast(true));
In some cases (for some OS's) you should transmit packet to broadcast address instead of exact ip-address.
I am acquainting with BSD sockets, and flicking through the man page of sendto, I bumped into MSG_CONFIRM flag, which is quite mysterious to me at the moment.
The description says:
Tell the link layer that forward progress happened: you got a
successful reply from the other side. If the link layer doesn't get
this it will regularly reprobe the neighbor (e.g., via a unicast ARP).
Only valid on SOCK_DGRAM and SOCK_RAW sockets and currently
implemented only for IPv4 and IPv6.
After a quick look at the man page of arp, I understand that flagging something MSG_CONFIRM prevents the ARP mapping MAC address ↔ IP address of the remote machine from being considered stale.
Now I am puzzled because I can’t see any reason why I should not put it, and therefore, why didn’t they enforce that directly in the library. Why is the application layer expected to deal with anything that happens down there at the link layer.
So did I miss anything? when should I set it, or not set it?
You should only set the flag if the datagram you're sending is a direct response to a datagram you just received from the same peer.
If you're sending an initial request, or sending a datagram in response to some other event (like user input, or a timeout) then you should not set the MSG_CONFIRM flag.
The reason to not send it is in case the mac address for the IP changes over time. If you're constantly telling your system not to check, it will continue to send to the same MAC even if the IP address isn't there anymore.
It seems the case for sending it requires a very special situation where you can guarantee things about the recipient of your messages. The overhead of a periodic ARP request is very low, so the benefits are extremely limited.
This is my attempt at making sense of this after reading the other two answers here.
If you're wondering about when to use the MSG_CONFIRM flag, essentially, all it does is tell the underlying ARP network layer to NOT periodically verify the MAC of the recipient IP (which would update the ARP hardware-MAC-address-to-IP-address mapping), because we are confident the IP we are sending to is the device we think it is, since this message are are sending is in direct response to a message we just received from them! In other words, if in doubt, leave OUT the MSG_CONFIRM flag. Put it in ONLY if the message we are sending is a direct response to a message received, and therefore we want to increase the network efficiency a tiny bit by NOT verifying the MAC again periodically, at the risk that the destination MAC could change and be wrong and no loner match the IP address for the device we think we are sending this message to!
Pros of using MSG_CONFIRM:
It increases the efficiency of the network by NOT having ARP reprobe for the MAC of the destination address.
Cons or risks of using MSG_CONFIRM:
It may mean that if the old device on the network drops off, and a new destination device pops up on the network with the same destination address as the old one, but with a different hardware MAC, we won't know, because MSG_CONFIRM tells ARP not to reprobe that IP address's MAC.
When MSG_CONFIRM can be used:
When our message out is a direct reply to a message we just received in from that device, so we are sure its MAC is still correct.
MSG_CONFIRM in this case can be thought of as a "confirmation" message to the sender that we got their previous message.
Official documentation from here for sendto(): https://linux.die.net/man/2/sendto (emphasis added):
MSG_CONFIRM (Since Linux 2.3.15)
Tell the link layer that forward progress happened: you got a successful reply from the other side. If the link layer doesn't get this it will regularly reprobe the neighbor (e.g., via a unicast ARP). Only valid on SOCK_DGRAM and SOCK_RAW sockets and currently only implemented for IPv4 and IPv6. See arp(7) for details.
So, my rule of thumb is: just don't use it. It has little benefit. But, if you choose to use it, only use it
To reply (via a UDP message) directly to the sender of a UDP message just received via recvfrom(), or equivalent, or
In embedded device networks where you have fixed (static) MAC addresses, IP addresses, and ARP MAC-to-IP mapping, and carefully manually control it all, and care about the tiny bit of network efficiency gain achieved by disabling ARP probing.
I'm trying to set up a little test application on Linux (Ubuntu) based on some code I wrote (and that worked) for Winsock. As it stands now, it's just a little test that creates a socket (and seemingly successfully connects) only to hang eternally on recv() instead of receiving datagrams. It's a plain blocking socket.
Here's how I create it:
http://pastebin.com/kcCbgxbB
A few further things tested:
- Port is open.
- Other applications are able to receive data from the multicast address successfully.
So clearly I'm overlooking something. Help greatly appreciated :-)
In Unix systems, when using a socket for multicast you should bind to INADDR_ANY, not to a interface.
Multicast filtering by interface (i.e. not receive mcast from other interfaces than the specified one) is already in place because you are correctly filling imr_interface.
So, in the end a little system configuration and bugfixing went a long way:
a) As root, I'd had to do the following to disable the reverse packet filter:
echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
+ The same for ethX.
b) Add a bogus route for the ethX (route add -net 224.0.0.0. netmask 224.0.0.0 ethX)
c) Bind the socket to the to-be-joined group's IP (otherwise any subsequent socket would get all packets from all groups I joined on that particular port).
d) Set the interface member of the ip_mreq struct to the IP of the adapter we're receiving on.
And then all was fine and dandy, test runs fast & smooth (pulling 125 multicast transport streams # around 800-900 mbit - sure this can be smarter, but still). Thanks for all the pointers.
I am programming a Client/Server application for my project in C++. The whole application protocol was given or discussed by the working group. The main idea is that we have 3 protocols.
Text-protocol: send and receive some information in string format between client and server.
Binary-protocol: client sends continiously some status data to server.
Binary-protocol: client sends continiously some data like sound/video/images/text
All Protocols should run on different ports.
I implemented a Socket-Class, which is responsible to create and listen socket, accept the connection from the client. Also there is a function to receive/send string-based data and receive/send binary-based data.
In the next step I wanted to define 3 Classes. Each of them should be responsible for creating one socket in new Thread and responsible for the protocol, which was defined for that port (s. 1-3). So at the end I will get 3 Sockets (1 Socket for one Port).
My question is, if I think in right direction? Maybe you can recommend my some design patterns for using different application protocols. It would be great if you can recommend me some projects or code, which can be similar with my project.
Thank you.
You should decouple your socket class from the 3 protocol handlers - don't have methods for both text and binary data handling on the Socket or you unintentionally encourage people to mix and match data types over the same socket, which is clearly not what you want.
Your socket should provide simple connect/disconnect, data transmission and receipt functionality, and the decoding and encoding of sent/received data is then done in a different object, likely picked from 3 new classes (one per protocol).
On a general note, I question the use of text data. It's inefficient compared to virtually any serialization library you could name. You could be trading a little extra debuggability for a lot of hard-written data parsing and error checking code, and concomitant CPU cycle wastage. If the text data is fairly simple (not actually structured like XML, say) then this is less of a concern.
Protocol 2. might be implementable using UDP rather than TCP, if the status info is not mission-critical. That's one less connection you'd have to manage.
You might consider using enet. It does reliable and unreliable UDP communications and will do most of the heavy lifting of the communications for you.
Lots of questions, I am sorry!
I am doing a voice-chat (VoIP) application and I was thinking of doing a custom implementation of the IP&UDP headers, along with small, extra information mainly seq number. Sounds alot like RTP yes, but I'm mainly just interested in the seq number or timestamp, and trying to implement my own whole RTP sounds like a nightmare with all the complexity involved and data im not likely to use.
Target OS for the application is windows xp and above. I have read http://msdn.microsoft.com/en-us/library/ms740548%28v=vs.85%29.aspx on the topic of Raw sockets in windows, and now I just want some confirmation.
I also have some general networking questions.
Here's the following questions;
1) According to MSDN, you cannot send custom IP packets with a source that is not on the network list. I understand it from a security PoV, but is there any way around this? My idea was to have for example two clients open UDP communication to a non-NAT protected server, and then have the clients spoof the source-header to make it look like packets come from the server instead of each other, thereby eliminating the need for a server as a relay of data to get through NAT, which would improve latency.
I have heard of winpcap but I don't want each client to have to install any 3rd party apps. Considering the number of DoS attacks surely there must be some way around this, like spoofing the network table the OS uses to check if source-header is legit? Will this trigger anti-virus systems?
I feel it would be really fun to actually toy with IP headers and above instead of just using predefined headers.
2) I've been having issues with free RTP libraries like JRTPLIB(which probably is very good anyway it just dosn't want to work for me) to make them work, more than I could almost tolerate, and am thinking of just writing my own interpretation ontop of UDP. Does application-level protcols like RTP simply build their header directly inside the UDP payload with the actual data afterwards? I suspect this considering the encapsulation process but just want to make sure.
If so, one does not need to create a RAW socket to implement application-level protocol, just an ordinary UDP socket and then your own payload interpretation above?
3) RTP does not give any performance boost compared to UDP since it adds more headers, all it does is making sure packets arrive in a sort-of correct manner based on timestamps and sequence numbers, right?
Is it -really- that usefull to use an RTP implementation for your basic VoIP project needs instead of adding basic sequencing yourself? I realise for video conferencing perhaps you reaally don't want frames to play out of order, but in audio conversations, would you really notice it?
4) If my solution in #1 is not applicable and I would have to use a server as a data relay between clients, would multicast be a good solution to reduce server loads? Is multicast supported enough in routing hardware?
5) It is related to question 1). Why do routers/firewalls allow things like UDP hole punching? For example, two clients first conenct to the server, then the server gives a client port / ip on to other clients, so the clients can talk to each other on those ports.
Why would firewalls allow data to be received from another IP than the one used in making the connection on that very port? Sounds like a big security hole that should easly be filtered? I understand that source IP spoofing would trick it, but this?
6) To set up a UDP session between two parties (the client which is behind NAT, server whic his non-NAT) does the client simply have to send a packet to the server and then the session is allowed through the firewall? Meaning the client can receive too from the server.
Based on article at wiki, http://en.wikipedia.org/wiki/UDP_hole_punching
7) Is SIP dependant on RTP? For some reason I got this impression but I cant find data to back it up. I may plan to add softphone functionality to my VoIP client in the future and want to make sure I have a good foundation (RTP if I really must, otherwise my own UDP interpretation)
Thanks in advance!
1, Raw sockets seems unnecessary for this application
2, Yes
3, RTP runs on top of UDP, of course it adds overhead. In many ways RTP (ignoring RTCP) is pretty much the bare minimum already and if you implemented a half-way decent alternative it would save you a few bytes at best and you wouldn't be able to use any of the many RTP test tools.
7, SIP is completely independent of RTP. SIP is used to Initiate Sessions. SDP is the protocol commonly transported by SIP, and it is SDP that negotiates and controls RTP video/voice voice.