What is the difference between tcp::endpoint and udp::endpoint in Boost::Asio? - boost-asio

It seems boost::asio defines a separate endpoint class for each protocol, which is irritating if you want to perform both UDP and TCP operations on a particular endpoint (have to convert from one to the other). I'd always just thought of an endpoint as an IP address (v4 or v6) and the port number, regardless of TCP or UDP.
Are there significant differences that justify separate classes? (i.e. couldn't both tcp::socket and udp::socket accept something like ip::endpoint?)

The sockets are created differently
socket(PF_INET, SOCK_STREAM)
for TCP, and
socket(PF_INET, SOCK_DGRAM)
for UDP.
I suspect that is the reason for the differing types in Boost.Asio. See man 7 udp or man 7 tcp for more information, I'm assuming Linux since you didn't tag your question.
To solve your problem, extract the IP and port from a TCP endpoint and instantiate a UDP endpoint.
#include <boost/asio.hpp>
#include <iostream>
int
main()
{
using namespace boost::asio;
ip::tcp::endpoint tcp(
ip::address::from_string("127.0.0.1"),
123
);
ip::udp::endpoint udp(
tcp.address(),
tcp.port()
);
std::cout << "tcp: " << tcp << std::endl;
std::cout << "udp: " << udp << std::endl;
return 0;
}
sample invocation:
./a.out
tcp: 127.0.0.1:123
udp: 127.0.0.1:123

TCP and UDP ports are different. For example, two separate programs can both listen on a single port as long as one uses TCP and the other uses UDP. This is why the endpoints classes are different.

Related

Udp Packet error rate in omnetpp

I have a question regarding the error rate calculation in .cc file for udpapp.
errorRate = ((float)(numPKTDropped) / (float)(numReceived + numPKTDropped))*100;
EV << "Error rate= "<<errorRate<<"%, Sent= "<<numSent<<" , Received= "<<numReceived<< endl;
this is my code and its a duplex system. Udp packet receiver is unaware with the number of sent packets from sender. How could this be possible to know this via code in omnetpp.
I would suggest put a sequence number into the UDP payload so you will know on the receiving side if a sequence number is skipped (except the case when the last packets at the end of the simulation are lost). That would be a good enough estimation for the USP packet loss.

wireshark capture filter for specific UDP bytes

I need a capture filter for wireshark that will match two bytes in the UDP payload. I've seen filters with
UDP[8:4]
as matching criteria but there was no explanation of the syntax, and I can't find it in any wireshark wiki (needle in the haystack thing).
I need to only capture UDP 5361, and only packets that have the bytes 8C:61 as the third and fourth bytes in the payload. Something like
udp port 5361 and udp[2:2]=8C:61
But I'm guessing at this of course. Thanks for any help...
Stumbled on it:
udp port 5361 and udp[10:2]==0x8C61
UDP data field (payload) starts at offset 8, and I'm looking at payload bytes 3 and 4. The tip was in WireShark Wiki, after all.

Tx LPC2148 with Xbee in API mode with Rx Xbee with Relay not works

I started to work on lpc2148 with xbee series 2.
On the transmitting side i am using lpc2148 with xbee coordinator in API mode,
and Rx side i am using xbee on Shield in router AT mode.
I want XBee to activate a D3 pin, which could be used to turn on relay on Rx side
API frame format as below code using c program .
enter code here
#define Delimeter 0x7E
void Init_UART1(void) //This function setups UART1
{
unsigned int Baud16;
U1LCR = 0x83; // DLAB = 1
Baud16 = (Fpclk / 16) / UART_BPS;
U1DLM = Baud16 / 256;
U1DLL = Baud16 % 256;
U1LCR = 0x03;
}
void main() {
Init_UART1();
LED1_ON();
setRemoteState(0x5);//AD3 config DOUT HIGH
Delay(25);
LED1_OFF();
setRemoteState(0x4);//AD3 config DOUT LOW
Delay(25);
void setRemoteState (char value) {
UART1_Write(Delimeter);//start byte
UART1_Write(0);//high part of length
UART1_Write(0X10);//low part of length
UART1_Write(0X17);//remote AT command
UART1_Write(0X0);//frame id 0 for no reply
UART1_Write(0X0);
UART1_Write(0X0);
UART1_Write(0X0);
UART1_Write(0X0);
UART1_Write(0X0);
UART1_Write(0X0);
UART1_Write(0XFF);// broadcast
UART1_Write(0XFF);// broadcast
UART1_Write(0XFF);
UART1_Write(0XFE);
UART1_Write(0X02);//apply changes immediately on remote
UART1_Write('D');//writing on AD3 pin
UART1_Write('3');
UART1_Write(value);
sum = 0x17 + 0xFF + 0xFF + 0xFF + 0xFE + 0x02 + 'D' + '3' + value;
UART1_Write(0xFF - (0xFF & sum));//checksum
Delay(25);
}
}
i am not able to get any communication or data on my Rx side. D3 pinout volage is still low.
Please guide on this point...
This program is working fine with arduino using Serial.write Function.
Regards,
Vijay
Are you using the correct baud rate? Are you sure you've connected TX/RX correctly and haven't crossed them? If you have hardware flow control enabled, is the RTS signal into the XBee asserted? Is the XBee module powering up and receiving enough current?
If you monitor the XBee transmit signal on another device (computer via FTDI's TTL-to-USB cable) are you seeing bytes at startup (I believe it sends a Modem Status during it's startup)? If you monitor the LPC2148 transmit signal, are you seeing the byte stream you think you're sending (confirming that you're driving UART1 correctly)?
Can you tell if the XBee module is receiving your requests, perhaps by toggling ATD0 between high and low output and checking with an LED or scope? Do you have any hardware you can use to monitor the serial stream between the two devices to see if it's sending the bytes you think you're sending? Are you sure it's calculating the correct checksum (dump the bytes somehow and try running them through X-CTU to see if they work).
If you're going to be doing a lot of communications between the LPC2148 and the XBee module, you might want to try porting this Open Source ANSI C XBee Host Library to the platform. It includes multiple layers of XBee frame processing that should reduce the amount of software you need to write.

Broadcast address validation

How to validate broadcast IP address?
IP Addr: 192.168.36.226
Netmask: 255.255.255.0
Broadcast: 192.168.36.255
whether it is possible to provide any broadcast address (suppose 1.2.3.4). If yes what will be the impact on the communication to other network.
The IP address and netmask determine the broadcast address. You cannot use just any broadcast address, or anything requiring broadcast traffic will not work.
The netmask specifies the size of the subnet. A netmask of 255.255.255.0 is commonly represented as /24, meaning that the first 24 bits of the IP address specify the network ID, where the last 8 bits are for the individual host. 192.168.0.100/24 is a host on a network with an ID of 192.168.0.0 and a broadcast address of 192.168.0.255. The highest value available in the network is the broadcast address.
10.1.2.3/8's broadcast address is 10.255.255.255. Its decimal subnet mask is 255.0.0.0.
As Brad mentioned, if you have the netmask, then it's very easy to compute the broadcast address. You simply swap all the bits and do an OR with the main IP address.
Typing a mask such as 255.255.255.0 is now deprecated. Instead, you are expected to use a number of bits on the IP. For example: 192.168.36.226/24.
The number, 24, indicates the number of 1s starting in the most significant bit. This is the same principle with IPv6 which uses 128 bits instead. So those numbers are often much larger with IPv6.
One way to compute the mask for an IPv4, is to use -1 and 32 - size (which is our case is 32 - 24 = 8):
size = 24; // somehow you get this number...
...
unsigned int mask = -1;
shift = 32 - size;
mask <<= shift; // C++ operator, in C write: mask = mask << shift;
Now you can compute the broadcast address by flipping all the bits of the mask and ORing that with the IP:
broadcast_bits = ~mask;
broadcast_ip = ip | broadcast_bits;
I think that IPv6 does the same thing, but with 128 bits. Also IPv6 does not offer Multicast (IPs that match 224.0.0.0/4).
If your question was about finding the broadcast address as defined in the Interface of an Ethernet or similar network card, then the above code is not what you are interested in. Instead, you want to list the interfaces, list each IP address defined on each interface (on some systems you could have up to 65536 IPs on one interface). That list includes the broadcast IP address and the main IP address and a mask. In other words, you can do:
if(my_ip & mask == interface->ip & mask)
{
if(my_ip == interface->broadcast_ip)
{
return interface;
}
}
return nullptr;
The list of interfaces is accessed with the following:
struct ifaddrs * ifa_start(nullptr);
getifaddrs(&ifa_start);
for(struct ifaddrs * ifa(ifa_start); ifa != nullptr; ifa = ifa->ifa_next)
{
if((ifa->ifa_flags & IFF_BROADCAST) != 0
&& ifa->ifa_broadaddr != nullptr)
{
// found the broadcast address of that interface
}
}
With that information, you should be able to find the address and the mask used above. Note that all interfaces may not support the broadcasting (unlikely, I think).
For a complete implementation, see libaddr (C++). The interface implementation is found in libaddr/iface.cpp.

When is IPPROTO_UDP required?

When is IPPROTO_UDP required?
Is there ever a case where UDP is not the default protocol for SOCK_DGRAM? (real cases, not hypothetical "it might be", please")
i.e., what are the situations where the following two lines would not produce identical behavior?
if ((s=socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP))==-1)
if ((s=socket(AF_INET, SOCK_DGRAM, 0))==-1)
Some operating systems (eg. Linux kernel after 2.6.20) support a second protocol for SOCK_DGRAM, called UDP-Lite. If supported by your system, it would be enabled by providing IPPROTO_UDPLITE as the third argument to the socket() call.
It is differentiated from normal UDP by allowing checksumming to be applied to only a portion of the datagram. (Normally, UDP checksumming is an all-or-nothing effort.) That way, the protocol can be more resistant to checksum failures due to fragmented transmission, in the event that some fragments outside the checksummed area may have been lost in transit. As long as the fragments covering the checksummed portion were successfully received, as much of the datagram as possible will still be delivered to the application.
For backwards compatibility with existing code, I suspect (but I cannot guarantee) that the call socket(AF_INET,SOCK_DGRAM,0) will continue to default to normal UDP, even in systems that additionally support UDP-Lite.
Given these declarations:
tcp_socket = socket(AF_INET, SOCK_STREAM, 0);
udp_socket = socket(AF_INET, SOCK_DGRAM, 0);
raw_socket = socket(AF_INET, SOCK_RAW, protocol);
the ip(7) manual page in linux says:
The only valid values for protocol are
0 and IPPROTO_TCP for TCP sockets, and
0 and IPPROTO_UDP for UDP sockets.
For SOCK_RAW you may specify a valid
IANA IP protocol defined in RFC 1700
assigned numbers.
Those two lines in your questions will always produce the same result.