I am trying to add a queueing model (M/D/1) on the channel on the processMessage method but the problem in queueing model that I have to send selfmessage which is not supported by cchaneel class? so how can I make processMessage work as cSimpleModule class ( which allows sending selfmessage to it self?
You should NOT queue messages inside a channel, just as in real world, packets are not queued on your ethernet cable while a transmission is in progress. Instead, the sending node's network interface knows when the transmission will finish and the network interface itself queues up the extra messages until the wire gets free. So the queue should be in the network interface card (which is a module). See the routing example that does exactly this:
https://github.com/omnetpp/omnetpp/blob/master/samples/routing/node/L2Queue.cc
Related
I was testing my transmitter application on an ethernet interface and I deliberately put down the interface using "ifdown eth0". This stopped the message transmission and socket function "sendto" raised err ENETUNREACH. When the same interface was brought up again using "ifup eth0", message transmission resumed automatically.
However, when I am doing the same steps using bonded ethernet interface, then the error is not recovered. In other words, "sendto" gives ENETUNREACH error when bonded interface goes down. But when it is made up again, the transmission is not started back. Instead, the error is changed to "ENODEV".
Is there any action an application needs to perform on bonded interface failure, in order to recover from the same? If yes, how an application comes to know about the failure?
In case of infiniband bond, application receives RDMA errors like PORT_ERR so it is easy to reconnect the socket.
Also, is there any specific bond configuration which may auto-recover from such failures or indicate the application about the same. As far as I understand, the bonded interface should behave like a normal interface and should auto-recover from the failure.
Appreciate your help!
I have used UDP protocol for sending packets to the receivers. Can anybody please tell me how can I guarantee that my udp packets are received at the receiver. I can not implement TCP protocol for some reasons. So please suggest that is there any mechanism by which I can guarantee that my packets are received at the receiver.
You cannot guarantee that your packets arrive at the receiver. All you can do is to check with the receiver that your packets have arrived there. And there is no builtin mechanism to do this - you are on your own to implement this.
This can be done for example by letting the receiver send an acknowledgement whenever a packet is received, by periodically asking the receiver which packets were received etc. The best way depends on your actual (and unknown) use case.
Of course this need to be explicitly implemented inside your application protocol and thus inside your applications on both sides of the communication.
I'm having issues understanding what socket types are negatively impacted in the event that TCP must try retransmmitting messages.
We have a distributed system that uses a combination of inprocess and TCP connections for internal processes and external devices and applications. My concern is that in the event there is a significant traffic that causes latency and dropped packets, that a TCP retransmit will cause delay in the system.
What I'd like to avoid is an application that has messages compile in a queue waiting to be sent (via a single ZeroMQ TCP socket) because TCP is forcing the socket to repeatedly retransmit messages that never sent an acknowledge.
Is this an issue that can happen using ZeroMQ? Currently I am using PUSH/PULL on a Linux OS.
Or is this not a concern, and if not, why?
It is crucial that messages from the external devices/applications do not feed stale data.
First, the only transport where retransmits are possible is TCP over an actual physical network. And then likely not on a LAN, as it's unlikely that Ethernet packets will go missing on a LAN.
TCP internal to a computer, and especially IPC, INPROC, etc will all have guaranteed delivery of data first time, every time. There is no retransmit mechanism.
If one of the transports being used by socket does experience delays due to transmission errors, that will slow things up. ZMQ cannot consider a message "sent" until it's been propagated via all the transports used by the socket. The external visibility of "sent" is that the outbound message queue has moved away from the high water mark by 1.
It's possible that any one single message will arrive sooner over IPC than TCP, and possible that message 2 will arrive over IPC before message 1 has arrived via TCP. But if you're relying on message timing / relative order, you shouldn't be using ZMQ in the first place; it's Actor model, not CSP.
EDIT For Frank
The difference between Actor and CSP is that the former is asynchronous, the latter is synchronous. Thus for Actor model, the sender has zero information as to when the receiver actually gets a message. For CSP, the sending / receiving is an execution rendevous - the send completes only when the receive is complete.
This can be remarkably useful. If in your system it makes no sense for A to instruct C to do something before (in time, not just in A's code flow) instructing B, then you can do that with CSP (but not Actor model). That's because when A sends to B, B receives the message before A's send completes, freeing A to then send to C.
Unsurprisingly it's real time systems that benefit from CSP.
So consider ZMQ's Actor model with a mix of TCP, IPC and INPROC transports in ZMQ. There's a good chance that messages send via TCP will arrive a good deal later than messages sent through INPROC, even if they were sent first.
IS there a way I can in user-space get notification about a packet being dropped at Layer-2 in 802.11.
According to my understanding what happens is, when a packet is sent out on the medium, there are Layer-2 ACKs which are received if it is delivered correctly (if not,it does the retransmission and ultimately drops the packet if not delivered after several retries..)
I want to be able to access this notification (in user-space)and change the behavior of packet transmission.
I want to be able to send the packet to another host from the FIB rather than dropping the packet.
I have read about libpcap libraries and netfilter hooks which allows me to capture packet and inject them back on the networking stack..
But I'm not able to find hooks (if any, for the wireless stack) to help me capture the packet notification in Layer-2.
Please correct me if I'm not understanding something correctly. Also, any heads-up or links to read would be great.
No, you cannot, at least not using the standardised sockets interfaces. 802.11 is a link layer, and the sockets API is strictly link-layer agnostic: unless it's going to work on all link layers, it's not in sockets. There are good reasons for that: the kind of cross-layer interaction that you envision has been tried many times, and it's always turned out more trouble than it's worth.
You didn't give us any details about the application — but the best solution is most probably to change your application-layer protocol to send explicit acknowledgments, and send your data over the fallback route when you fail to receive an ACK.
I'm developping a little data processor in c++ over UDP sockets, and have a thread (just one, and apart the sockets) that process the info received from them.
My problem happens when i need to receive info from multiple clients in the socket at the same time.
How could i do something like:
Socket foo;
/* init socket vars and attribs */
while (serving){
thread_processing(foo_info);
}
for multiple clients (many concurrent access) in c++?
I'm using winsocks atm on win32, but just get standard blocking udp sockets working. No gui, it's a console app.
I'll appreciate so much an example or pointer to one ;).
Thanks in advance.
UDP socket is able to receive datagrams from multiple clients with the recvfrom() function. Just block on receive, read the request, process it, send the reply, repeat. You don't even need a thread unless processing takes a very long time (in that case a thread connected with two queues, in- and out-, would work).
I would suggest this is best tackled by putting the requests in a queue and letting the other thread work off the queue. This decouples the socket receive from the process and thus allows you to scale to more listeners and processing threads if your requirements change.