I'm currently implementing my first application in Contiki on a Telos bmote and encountered a problem.
For my application (which utilises the uIP IPv4 stack) I need to be able to broadcast messages to all nodes.
I have looked through the source and found that in uip_over_mesh.c the packet is found to be for an external network and is then being sent to a gateway node on the network instead of being distributed to all nodes. If no gateway node is present it just drops the packet.
So in fact rather than the packet being broadcast to all the nodes in the network it's either just being dropped or being sent to just the gateway node and external network.
My problem is that I need it to broadcast to the other nodes in the network(as it should), is there a step I'm missing or am I doing something wrong?
Thanks :)
p.s. This is the rough code to get the message to send.
struct uip_udp_conn *udp_conn = udp_broadcast_new(UIP_HTONS(5001), state);
udp_bind(udp_conn,UIP_HTONS(5001));
uip_udp_packet_send(udp_conn, "hello",5);
Sorry that my question didn't seem clear. To clarify what I wanted to do was send an IPv4 UDP packet to the broadcast address i.e. send to all devices on the network using the all ones addr. But I found that the sending device would only forward the message to a gateway node if it was present on the network.
The question is not clear but what I understand from the question you want to broadcast a message anonymously to all neighbour motes. You have two choices to go.
If you are using RIME stack from contiki. There is already a code under example/rime/example-broadcast.c (have a look at line 79,80 ( packetbuf_copyfrom("Hello", 6); broadcast_send(&broadcast)); I have tested the code and it is working perfectly fine under teleosB. I strongly recommend you to go with uIP (IPv6) stack using RPL. For a large network it 'll be extremely hard to maintain rime stack.
You can use udp based ipv6 enable broadcast example from examples/ipv6/simple-udp-rpl. You do n't need to change anything for receiver function unless you want more additional features. This function 'll print receiver port, sender port and data length. You can add "addr" from "uip_ipaddr_t" in the receiver function if you want to print IP addresses. For sender the lines of code are (76-91). You do n't need to change for simple message like "hello". I tested the code and it works perfectly fine.
After lots more reading of the Contiki source I found that the problem lay in uip_over_mesh.c.
When a broadcast message(255.255.255.255) was being sent it was tripping up when the send function would check if the destination was within the local network (based on the netmask and destination address). Failing this it would then try to send it out to a local gateway(if one existed) to route it out of the network.
Although IPv4 UDP broadcast had been built into the api, I saw no evidence of it actually being implemented in the uip_over_mesh.c(I might be wrong and totally missed it). So to fix this I added a broadcast RIME channel and added a check for the all ones address where the previously mentioned gateway check was. A method to receive the broadcast messages was also implemented ensure broadcast message were correctly received and passed to the upper layers.
From what I gathered from here and the mailing list, IPv6 is where the focus is and not many people are knowledgeable or using the IPv4 uip stack. When I get some time I will dig up my modified uip_over_mesh.c and see if I can push the modifications, though I'm sure it's a bit of a hack and not of much use due to the above mentioned lack of interest.
Related
I have multiple readers on a single system which bind to a single address (IP:port ex. 239.0.0.1:1234). Another computer on group sends a UDP multicast packet to this group and readers should receive it. I used GLib 2.0 networking stack, g_socket_bind with allow_reuse set to true.
When there is a single reader (single socket binded to that address) or up to three readers everything is ok and readers will receive packets correctly. But when the number of readers increases to four or above, the packet loss occurs and linearly increases with number of readers on system.
If socket is a UDP socket, then allow_reuse determines whether or not other UDP sockets can be bound to the same address at the same time. In particular, you can have several UDP sockets bound to the same address, and they will all receive all of the multicast and broadcast packets sent to that address.
As stated in GIO Reference Manual, when allow_reuse set true, all readers should read all of data but it doesn't happen as the stated above.
Anybody knows what the problem is? Is there a kernel related problem?
All your sockets need to join the multicast group. If you're just relying on the bind to effect that, you are into undefined behaviour.
I want to implement a demo application to listen data via TCP/IP.
Data Transmitter will transmit a series or ASCII char or a series of string all the time. It feeds data into TCP/IP address (eg. 127.0.0.1:22) This could be a GPS transmitter.
I want to implement a demo application for receiving data by clicking the start button and listening to the data via TCP/IP and display it accordingly.
Correct me if I am wrong, I don't think I can use Server/Client server for this purpose. I tried to create a client application with TIdTcpClient, it receives only one time data. I don't think Indy has a TCP listening component.
Thanks in advance.
If you wanna monitor network comunications between some device and some other program on your computer using of TIdTCPServer won't work. Why? Once Indy will read network data it will mark it as processed and delete it from network buffer. So that data probably won't even reach to the other program on your computer. Workaround for this is that you design your application to actually work similar as network bridge. Your application listens to the data on one port and then forwards that data on another port on which the other program is listening. But the main problem is that you have to make this to work both ways.
What you need is somekind of a component which is able to peek at the network data but don't interact with it. This is usually done on driver level.
Now if it is not abolutely necessary to have such functionality in your own software but you are only interested in getting the data I recomend you try Wireshark (http://www.wireshark.org/). Wireshark is a verry powerfull freware software which alows you to monitor all netwrok traffic on basically all protocols without causing any interuptions. In order for this software to work it instals special driver which serves for intercepting the network data.
Maybe you would want to use same driver in your application if this functionality needs to be in your application.
Based on your diagram I think that your implementation could also be based on a message-oriented middleware, using a message broker which receives the GPS transmitter or other data.
The message broker would then store the data internally and forward it to all interested clients which are connected. A typical messaging pattern in this case is a "Topic", which broadcasts the messages similar to a radio station.
So the middleware will ensure that the information will be collected (optionally also persisted to disk) and then guarantees the delivery to the receivers. This can be done even in a way where receivers which have been off-line for a while still receive the GPS messages created while they where not listening ('retroactive consumers').
There are many popular free open source message brokers, and most of them also can be used with Delphi.
There is a lot of other answers related to this issue, however I believe this is specific.
I am using Delphi XE2 and Indy 10.5.8 and TIdUDPServer
In my local development network I have everything on the same network ip subrange and all connected to the very same Access Point (LinkSys)
I have Androids sendind UDP Broadcast to 255.255.255.255 to request the server ip address that is written in Delphi listening using TIdUDPServer on the port 44444.
The requests get there fine and I can answer back no problem. Works exactly as expected.
However I have noted that in some networks it does not work! It is always simple networks based on an access point, I am not sure but seems that where the problem happens the server PC is connect to the LAN port while the devices are using the wifi, all in the same access point.
Could be the case that the access points do not broadcast the UDP packet by the both LAN and wifi? I know that this kind of broadcast is very limited, but I have not found any information that tell me that in the same access point there is limitations like that.
Is there are ways to test, or workaround?
This solution needs to be strong enough to deal with the many AP out there.
EDIT: For those that want to get the source code for retrieving more information from the network including the broadcast ip as mentioned on the answer below follow this solution, it is all there.
http://www.code10.info/index.php?option=com_content&view=article&id=54:articleretrieve-network-adapter-information&catid=47:cat_coding_algorithms_network&Itemid=78
255.255.255.255 is not the best option for sending UDP broadcasts, and some routers/firewalls do block it unless configured otherwise. The better option is to use the NIC's actual subnet broadcast IP instead. For example, if a UDP socket is bound to local IP 192.168.0.1 with a subnet mask of 255.255.255.0, then the broadcast IP for that subnet is 192.168.0.255.
Most platforms have OS-specific APIs for retrieving a NIC's actual broadcast IP, such as getifaddrs() on POSIX systems, or at least for retrieving the NIC's subnet mask, such as GetAdaptersInfo() and GetAdaptersAddresses() on Windows, so you can calculate the broadcast IP manually.
Retrieving the local broadcast IP(s) may be added to Indy in a future version.
I spent the last two days reading each StackOverflow questions and answers (and googling of course) about Indy TCP and UDP protocol in order to decide which one should I use in my communication method between my User Application and my Windows Service.
From what I saw so far, UDP is the easiest and the only one I managed to work to receive broadcast messages from TidUDPClient (I did not testes the response back yet). And I also noticed that TCP is a bit more complicated with it's thread loop.
But since everywhere I am told UDP is not reliable, UDP is not reliable... I begin to wonder if it's not better to use TCP anyway.
My User Application will be running on many machines, and the Service will be running in one of them, sharing one IP with a Client, or in a dedicated machine, depending on my client's funds. So, should I really be worried about UDP data loss possibilities?
I need broadcast capabilities so my server advises all clients at once about Application updates, and of course, if my the Client Application does not know in which IP the Service/Server is, it will send a broadcast call to be told where the server is. Is that applicable to TCP?
The messages I am sending are requests for users access confirmation, users privileges, and application executable file updates, since the main application can't update itself.
Those messages are encrypted like below, and they might bet bigger sometimes.
e86c6234bf117b97d6d4a0c5c317bbc75a3282dfd34b95446fc6e26d46239327f2f1db352b2f796e95dccd9f99403adf5eda7ba8
I decided to use them both!
Simple use case:
In order to communicate with TCP prococol you have to establish a connection which you can have only if you know IP and Port on both ends.
If you do not have that information when you load your Application, then you use the UDP to Broadcast your IP address and your intention to find the/a Server. You may try about 5 times before you raise the user an error telling that you did not find the Server or that the Server is down.
Sending that message in UDP will (one time or other) reach the UDP ear of the Server, which will now know the IP from the lonely Client's IP and will now begin a proper connection via TCP to be read talk about the critical messages of the Application.
What do you think of that approach?
I am using UDP network protocol to send message from various clients to a root server.
The message from client to server may not be sent directly and may be sent via other clients.
I want to know the clients via which the message is sent by looking at the message received at the root server. How to do this?
UDP does not include this information. You'll need to include something in your protocol if you want to keep track of servers through which the message has passed.
The traceroute program uses a trick to get bounced packets by setting the TTL to an increasing number. It starts with a TTL of 1 so that the first bounce comes from the closest server to the source. It then tries a TTL of 2 to get a bounce from the second server on the path, and so on.
traceroute is client-side and heuristic, i.e. works only for stable connections. Since you are essentially constructing an overlay network, the only ways to get information about the route is reconstructing the routing according to your routing algorithm (hard, and probably infeasible in a distributed network) or having each relay add a note (typically consisting of the relay's name, and the previous IP address) to the message.