How message reception order is modeled under Omnet++? - network-programming

I read a lot about messages Sending/Reception under Omnet++, but currently i am asking my self about reception order under Omnet++.
Let say that:
I am using a WIFI network card
I want to send two messages from A to
B
The question is: If i send msg1 then msg2, is it possible that i receive msg2 before msg1 ?
Based on what i know and what i read, i guess that is not possible, but i will be greatfull if some one can confirm/invalidate it.
Thanks,

After reading properely Omnet++ documentation and by taking into account the evenemential model of the simulator.
It appears that is possible if event related to msg2 reception is scheduled before the one related to msg1

Related

When can i use SendChatMessage after logon?

After logon, i would like to send a chat message to the Guild channel.
I'm currently listening for events:
PLAYER_ENTERING_WORLD
GUILD_ROSTER_UPDATE
Once those have fired (in order), i'd like to send a chat message. However, it never sends.
Code:
print("Should_send")
SendChatMessage(msgToSend, "GUILD");
It's also worth noting that if i then trigger this manually, it works.
I do see the "Should_send" print statement appearing in the default chat window each time - as expected. I've also checked that "msgToSend" contains content - and is less than 255 characters.
So, when can i call SendChatMessage?
Ok, in order to be able to send a chat message to guild, you need to wait for the event "CLUB_STREAM_SUBSCRIBED" to fire.
This is due to the Guild channel becoming a "community" channel of sorts - previously, it seems this wasn't required.
So, adding an event listener:
frame:RegisterEvent("CLUB_STREAM_SUBSCRIBED");
Resolves the issue.
You will likely need to set a flag for the event, then print later on another event.
You can send chat messages any time after you see the welcome message or after the welcome message was posted. Which is pretty soon after you able to receive events from your frames.
Here is what I would do to complete a similar mission:
Just put your send code in a macro to test it first. Don't worry about timing the message until you see it work in a macro.
You can make your own print to send generic messages to the chat window which should always work similar to:
function MyPrint( msg, r, g, b, frame, id)
(frame or DEFAULT_CHAT_FRAME):AddMessage(msg, r or 1, g or 1, b or 0, id or 0)
end
-- put these in your event handlers
MyPrint("event PLAYER_ENTERING_WORLD")
MyPrint("event GUILD_ROSTER_UPDATE")
And use that for debugging instead.
You need to divide and conquer the problem, because there are so many things that could be wrong causing your issue, no one here can really have a definitive answer.
I know for sure that if you try to write to chat before the welcome message with print it at least used to not work. I remember spooling messages in the past until a certain event had fired then printing them.

TinyOs nesc Packet acknowledge

I want to write a mote-mote radio communication program, and want the receiver acknowledges back to the sender. I know the PacketAcknowledgements is recommended, but there are some questions I'm not sure about this interface.
1. If I use it in the sender mote,should i also uses interface Receive in the module of the sender mote
2. Should I write extra code in the receiver mote? Should I use interface PacketAcknowledgements too?
3. command error_t requestAck(message_t *msg) and command bool wasAcked(message_t *msg) should be used when and where
No.
No.
You need to call requestAck on a packet you're about to send just before calling send from interface AMSend or Send. Be sure to check an error code returned by requestAck, because FAIL indicates that the communication layer doesn't support synchronous acknowledgements (it depends on the radio chip and driver you use). Once the packet is sent, i.e., inside event sendDone (or later), call wasAcked, which returns true if the packet was acknowledged by the receiver.
More info in:
https://github.com/tinyos/tinyos-main/blob/master/tos/interfaces/PacketAcknowledgements.nc

How to know when scan is finished

I trigger the scan with following code
struct nl_msg *msg = nlmsg_alloc();
struct nlmsghdr *hdr;
struct genlmsghdr cmd = { .cmd = NL80211_CMD_TRIGGER_SCAN };
struct nl_sock *sock = nl_socket_alloc();
int dev = if_nametoindex("wlan0");
nla_put_u32(msg, NL80211_ATTR_IFINDEX, dev);
hdr = nlmsg_put(msg, NL_AUTO_PID, NL_AUTO_SEQ, NLMSG_NOOP, 0, 0);
memcpy(nlmsg_data(hdr), &cmd, sizeof(cmd));
nl_send_auto(sock, msg);
Now, how should i know when scan is finished, and how can i get it? In all places i have been searching so far, there is "You will receive NL80211_CMD_NEW_SCANS notification on "scan" multicast group", How should i subscribe to it? i registered my callback, tried
nl_socket_add_memberships(sock, RTN_MULTICAST);
and after that listen for messages in while with
while (1)
nl_recvmsgs_default(sock);
but nothing happened, so: if you had enough patience to read up to this point, please help me with 2 questions
1) How do i know when scan is finished(how to subscribe on this notifications, or read them etc.)
2) How can i read messages after notifications received(method as i understand it below)
To read scanned data i need to send message similar to one that triggers scan, but with message NL80211_CMD_GET_SCAN, and after that data will be stored in nl_socket's payload, am i right?
send a NL80211_CMD_TRIGGER_SCAN to start a scan off. (one after another will fail)
After sending, then listen out for the scan to complete when you get a NL80211_CMD_NEW_SCAN_RESULTS.
a NL80211_CMD_GET_SCAN command to ask for the results.
You will get one message back for every station found, so be ready to handle multiple messages.
NL80211_CMD_TRIGGER_SCAN to scan off
listen to NL80211_CMD_NEW_SCAN_RESULTS
NL80211_CMD_GET_SCAN command to ask for the results
should get one message back for every station found

Does erlang:disconnect_node/2 immediately stop queued messages?

If I sent a lot of messages to a remote node and immediately call erlang:disconnect_node/2 to drop the connection, is there a chance some messages don't get through the wire? In other words, does that method perform a brutal disconnection, regardless of waiting messages?
No, even with two local nodes!
Setup: I got a node a#super, on witch a dummy receive-print loop runs, registered with a. On another node, I run
(b#super)1> [{a, a#super} ! X || X <- lists:seq(0,10000)], erlang:disconnect_node(a#super).
That is, many messages, and then a brutal disconnection.
Result: the receiver printed the full 10001 messages only once over 10 runs.
So, you definitely do not have any guarantee the receiver got all the messages. You should use another technique (novice at erlang, sorry), or use an ack message before the disconnect.

erlang gen_tcp send issue

Could you please help me? I've a problem related with the gen_tcp send function. I've been trying to send few tuples, about 10-15 items, which were decoded to amf objects, from my erlang server to my flash client.
case get_tcp:send(Socket, Msg) of
ok -> io:format("sent~n");
{erorr, Err} -> io:format("~w~n", [Err])
end
No errors but the flash client doesn't recieve whole data just about 8-11 items. The socket options are [binary, {active, true}, {reuseaddr, true}]. I've checked my network where I use the client - sent packets were fragmented into two fragments, big and small ones. The big one is the first fragment of packet and small one is the next. Amount of the bigs is the same as amount of sent messages, but the smalls are much less and about number of received messages by the flash client.
It only reproduces if I send data fast, if I do it slowly it seems ok. Does anyone know why it happens? It will be very helpful.
My guess is that this is a framing issue.
TCP is a streaming protocol, so when you read in flash, you are not guaranteed to get all the messages right away. Rather you need some kind of framing setup, say {packet, 2} or {packet, 4} on the socket options. This effectively turns TCP from a streaming protocol into a messaging protocol. And I think you want the latter.
I think you can do like this:
1 Before send msg(your tuple), use term_to_binary(Msg) to get binary, then sizeof the binary, then, after your client receive the msg, use binary_to_term to get tuple.
2 Both the client and server you need to set the socket option{packet, 2 or 4}
I not tried amf, but I use erlang+flash and json instead of amf
What packet option of socket? (I use {packet, 2}, for example)
How did you read data on client side? Maybe you not read all data to end and no new events raised?

Resources