I am studying X-MAC in multihop sensor network. I am using AODV as a routing protocol. During run time, at the beginning, I can see that the sensor node starts sending preambles before any route discovery. So, until any route is established these preambles are sent for nothing.
I also studied the same network with csma/ca, in which the route is established first and then the node initiate transmission.
As per suggestions given in OmNET++ group, I tried the following, but it did not resolve the issue.
**.useHelloMessages = true
Would anyone please advice how to configure X-MAC so that when the simulation starts, a node will first establish a route and then it will send preambles for data communication?
Thank you.
At the start of the simulation, there are no routes. So when one of the nodes have some data to send (they contain a TCP app that generates a TCP packet, for example), the AODV initiates route discovery to the destination of the data (the TCP packet).
Aodv does this route discovery by sending an Aodv route request message (AodvRreq). The message indicates that the node wants to discover a route to the destination of the data.
Aodv is implemented as an app in INET, and it sends its route request (and other) messages encapsulated in UDP packets.
The packets (aodv or data) go down the protocol stack to the XMAC for transmission.
So, from the point of view of the XMAC, the Aodv route request message (which is triggered by the node wanting to send TCP data) is itself treated as data (since it uses UDP). In order to send data, the XMAC first sends preambles.
(Answer edited for more details)
Related
I have a sample message flow where a TCP Output Node communicates to an external system and receives response to a TCP Client receive node. My issue is, is there a way whether I can ensure that the TCP request and TCP response are correctly mapped and processed. We have observed in certain circumstances few request and responses getting mismatched. I understand there is a $LocalEnvironment/Destination/TCPIP/Output/Id property in the TCP IP Client Output Node and $LocalEnvironment/TCPIP/Receive/Id in the TCP IP Client receive Node. Should these be same for a single request and response? Should I write an ESQL check to ensure the request and response are correlated? Any advice would be very much helpful.
I have a situation
When i am making the diagnostic request from canoe. ECU responding with the response(Request correctly received but response pending). After some time i am getting positive response from the ECU. I just want to send the positive response from the current bus to another bus by cutting out the response pending response. How can i do that using capl?
You need to implement a gateway. I.e. a node connected to the two busses. For one bus, the node acts as a tester (sending requests and listens to responses) for the other bus, the node acts as ECU.
You listen for responses in one bus by using on diagResponse CAN1.* and if it is a positive response you send it to the other bus by using diagSendResponse CAN2.<responseMessage>
Replace CAN1 and CAN2 with the actual bus names.
Also check the Applications Note called Diagnostics Gateway or something like that coming with CANoe.
Another option is to do this not on the application layer but on the data layer. I.e. not by listening and forwarding diagnostics messages but by listening to the transported data.
What makes more sense for you depends on your exact setup; but details are unknown.
I want to design a system which reduces travel time of packet what is happening, in reality, am I send an SYN bit from the client side, this bit travel through the router then to server and server reply SYN+ACK which also travel through the router to the client.
So I just want something else like what if the client sends SYN to router, router then send this to server and copy this packet modify SYN to SYN+ACK and send back to client before server can send after server send this SYN+ACK to router, router just accept it(see it as the reply is coming) and discard it.
To achieve above goal, I design a setup in which I have one laptop which sends and receive packet from two ethernet interface and other one is desktop which acts as router(packets are coming and it only forward it to its destination) I set up the routing table from both side and enable the IP forwarding on desktop(which act as router).
All are working fine, on a laptop I have server and client program which send the packet and receive it but the problem is that I want to send the packets to from where it was coming (to source itself) so I modify the packet on routing side using Netfilter module, copy the entire skb(using skb_copy) and interchange its ip source and destination(I did this on NF_INET_PREROUTING) and also interchange the port number but the packet always goes to destination.
What other modification do I need to be done to send the packet to its source itself?
Before all, you have to deal here with some details.
First, on SYN-ACK packet, the server sends its sequence. So if in the router you modify the packet and send back to client, what will be your sequence? It's should be the same like the server will send and the server did not send anything yet.
Second, in the handshake there are several agreements like MSS, SACK enabled etc. So you can't to it on behalf of server.
About the question itself, you should do it in PRE_ROUTING, change the IP addresses and ports, and fix the checksum of both IP and TCP.
ZeroMQs Pub/Sub pattern makes it easy for the server to reply to the right client. However, it is less obvious how to handle communication that cannot be resolved within two steps, i.e. protocols where multiple request/reply pairs are necessary.
For example, consider a case where the client is a worker which asks the server for new work of a specific type, the server replies with the parameters of the work, the client then sends the results and the server checks these and replies whether they were correct.
Obviously, I can't just use recv,send,recv,send sequentially and assume that the first and the second recv are from the same client. What would be the idiomatic way to use multiple recv,send pairs without having to handle messages from other clients inbetween?
Multiple Request/Reply pairs can be made through the use of ZMQ_ROUTER sockets. I recommend using ZMQ_REQ sockets on the clients for bidirectional communication.
If you want to have multiple clients accessing a single server you could use a router socket on the server and request sockets on the clients.
Check out the ZMQ guide's section on this pattern:
http://zguide.zeromq.org/php:chapter3#The-Asynchronous-Client-Server-Pattern
All the clients will interact with the server in the same pattern as Pub/Subs except they will all point at a single server Router socket.
The server on the other hand will receive three messages for every single message a client sends. These parts represent:
Part0 = Identity of connection (random number of which client it is)
Part1 = Empty frame
Part2 = Data of the ZMQ message.
Reference:
http://zguide.zeromq.org/php:chapter3#ROUTER-Broker-and-REQ-Workers
The identity can be used to differentiate between clients accessing on a single port. Repacking the message in the same order and responding on the router socket (with a different data frame) will automatically route it to the client who sent the message.
In a recent series of question I have asked alot about UDP, boost::asio and c++ in general.
My latest question, which doesn't seem to have an answer here at Stackoverflow, is this:
In a client/server application, it is quite okay to require that the server open a port in any firewall, so that messages are allowed in. However, doing the same for clients is definately not a great user experience.
TCP-connections typically achieve this due to the fact that most routers support stateful packet inspection, allowing response packets through if the original request originated from the local host.
It is not quite clear to me how this would work with UDP, since UDP is stateless, and there is no such thing as "response packets" (to my knowledge). How should I account for this in my client application?
Thanks for any answers!
UDP itself is stateless, but the firewall typically is not. The convention on UDP is that if a request goes out from client:port_A to server:port_B, then the response will come back from server:port_B to client:port_A.
The firewall can take advantage of this. If it sees a UDP request go out from the client, it adds an entry to its state table that lets it recognise the response(s), to allow them in. Because UDP is stateless and has no indication of connection termination, the firewall will typically implement a timeout - if no traffic occurs between that UDP address pair for a certain amount of time, the association in the firewall's state table is removed.
So - to take advantage of this in your client application, simply ensure that your server sends responses back from the same port that it uses to receive the requests.