I'm using SipUnit to test my sip application which just forward the request. In my simple test case, user1(simulated with SipPhone) send Subscribe request and my application forward the request to user2(simulated
with SipPhone) and then user2 send reply by using JAIN ServerTransaction.sendResponse() method.
Then user2 send Notify to user1 using JAIN SipDialog.sendRequest().
And from the wireshark there is a problem in this Notify request: the CSeq is "1 Notify", but it should be "2 Notify" as it is in the same dialog as the Subscribe so the sequence number should be increased by 1.
Any idea?
When one party (say A) sends SUBSCRIBE to another (say B), then the NOTIFY will typically come from the B side and each direction, both (A to B) and (B to A) count the requests separately. So SUBSCRIBE will be CSeq 1 from A to B, and the NOTIFY will be CSeq 1 from B to A.
Related
I'm using 0MQ to let multiple processes talk to each other (IPC sockets, but should also work via TCP across different nodes). My code is similar to a client/server pattern, but REQ/REP sockets are not enough. Here is a sample conversation. See below for further details.
Process A
Process B
open socket
not started
start process B
-
-
open socket, connect to A
-
send hello (successful start, socket information)
request work
-
-
do work
-
send response (work result 1)
-
send response (work result 2)
-
send unsolicited message
-
send response (work finished)
request termination
-
Actually, A is (even though doing all the requests) closer to be the server component, since it is constantly running. Based on external triggers, A starts a sort of plugin process B.
Every request needs to be answered by a finished response. Before that, N (between 0 and an arbitrary upper bound) responses can be sent from B.
A new request can be sent from A even when the current request is still ongoing (no finished message received). If relevant, the code could be updated to buffer the requests.
B sends an initial message which is not preceded by a request from A.
B can send other messages (logging) anywhere in between, also not preceded by a request.
Optional: A single socket in A should handle multiple plugin processes B, C, D...
A DEALER/ROUTER combination would probably match all requirements, but might be a bit too much. Process B will only ever connect to a single peer. And without the optional requirement above, the same would be true for process A as well. So I'm a bit hesitant to use DEALER and ROUTER sockets which are both able to handle multiple peers.
I was asked this question in an interview and was unable to answer it.
How does FB messenger order the messages on user side when two messages are concurrent in order to avoid view difference in display order during the chat period and when user visits the messenger again. I thought that we can store a timestamp with each message, which is the time the message is received by the server. However, this will not ensure the correct ordering of messages for clients.
Take a scenario where the server timestamp cannot determine the exact order of messages would look like this:
User-1 sends a message M1 to the server for User-2.
The server receives M1 at T1.
Meanwhile, User-2 sends a message M2 to the server for User-1.
The server receives the message M2 at T2, such that T2 > T1.
The server sends message M1 to User-2 and M2 to User-1.
So User-1 will see M1 first and then M2, whereas User-2 will see M2 first and then M1.
I read that resolve this issue, we can use Vector clocks but was unable to understand how the message sequencing be preserved for different users during the chat and when users log in again.
In the above scenario, user1 will see M1 followed by M2 whereas user2 will see M2 followed by M1. Now if each user also generates a sequence number or timestamp for each of its message to each of the client (separately). Then in scenario above user1 will send message M1 with sequence <1 (user1 seq), 0(user2 seq) > and user2 will send message M2 with sequence <0 (user1 seq), 1(user2 seq) >. So when both the message arrives at user1 and user2 they will have:
M1 <1, 0>
M2 <0, 1>
Now let’s say user1 sends more messages M3 <2, 1> and M4 <3, 1> then each of client will have following msgs.
M1 <1, 0>
M2 <0, 1>
M3 <2, 1>
M4 <3, 1>
So in this case when the user is logged in the display order for user-1 and user-2 during chat will be M1,M2,M3,M4 and M2,M1,M3,M4 respectively. Now, I want to know how will the same order be preserved for user-1 and user-2 end when the login again ?
Thanks.
The problem here is how we will generate a consistent chat conversation for each user from these sequence numbers.
Let's assume a conversation between Alice and Bob.
Message sequence structure:
message<Alice seq number, Bob sequence number>
One thing to note is numbers in M1, M2, M3,... are just used to differentiate the messages and don't have any relation with the actual message sequence.
View from Alice side:
1) Alice sends M1<1,0>
2) Bob sends M2<1,1>
3) Alice sends M3<2,1>
Now, Bob sends one message(M5) but before Alice gets that, Alice sends one more message.
4) Alice sends M4<3,1>
And now, she received a message from Bob.
5) Bob sends M5<2,2>
Since Bob didn't get M4 before sending M5 the Alice sequence number in M5 is 2.
If he would have got that, the M5 would look like M5<3,2>.
Now, View from Bob side:
1) Alice sends M1<1,0>
2) Bob sends M2<1,1>
3) Alice sends M3<2,1>
Now, Bob sends message M5 before getting M4 from Alice
4) Bob sends M5<2,2>
5) Alice sends M4<3,1>
Now when Alice logins next time server will fetch the data and sort it:
1) First sort with Bob sequence number.
2) if two or more messages have the same Bob's sequence number then sort it in Alice's sequence number within them.
Similarly for Bob
1. First sort the message-ids with respect to Alice sequence number.
2. if two or more messages have the same Alice's sequence number then sort it in Bob's sequence number within them.
So for Alice, it would be in the order of Bob's sequence number:
M1<1,0>
M2<1,1>
M3<2,1>
M4<3,1>
M5<2,2>
For Bob, it would be in the order of Alice's sequence number:
M1<1,0>
M2<1,1>
M3<2,1>
M5<2,2>
M4<3,1>
How we will store the message sequences in the database:
How a client will know which is his/her sequence number?
In our example we decide that the first number will be Alice sequence number and the second will be Bob's. But in real-time how this decision will be made. This can easily be solved if we make a convention that the first sequence number will always be the sender's sequence number and the second one is receivers. So when someone receives a message then he knows that the first sequence number is the sender's sequence number. and when he prepares the next message he increments his sequence number from the last received message and puts it in the first place and takes the sender's sequence number from the received message and put it in second place.
How server will know that which sequence number has to be stored where?
Now since we defined the above convention if the server gets a message from Alice the first field will be Alice sequence number and the second will be Bob's sequence number so it will store in that way. Similarly, it does it for Bob also.
Note: I was also looking for the solution for the above problem but didn't get anything on the net that can help so made my own solution. Please correct me if it breaks any use case so that we can improve it or try something else.
Example:A,B clients are the same user,A sent messages To C.How to show these messages On B client.If C sent to this user,A，B also can receive messages.So l can show.But When A sent,B do not konw.
You should use message cabining.To share messages across all devices(clients) of same user.More details about it at https://xmpp.org/extensions/xep-0280.html
I'm trying to figure out if it is somehow possible to setup Mirth to send 2 ACK back to the caller Application:
A) 1 ACK sent from Mirth to the caller when the transmission has been received from Mirth;
B) 1 ACK sent from Mirth to the caller after the channel is finished processing the message.
I know that Mirth can either be configured to send ACK before processing (case A above) or after processing (Case B above), but I could not find any way to send both.
Has anyone had experience in doing this?
Thank you all for your help.
Mirth uses a single responseMap to store acknowledgement which is processed after all scripts. So, if you put anything there when a message is received, this Ack will be overridden with a new Ack placed into the same map at the end. And only the latter will be sent, which you've already experienced I guess.
If I'm correct, what you are trying to achieve is, first, to confirm that the message is received by a remote location (let's call it System B) and, second, is to confirm that the message successfully processed. If your client (System A) is capable to send a message to two endpoints at System B then you may create two receiving channels on the System B side, one of these channels sends ACK immediately after receiving the message and does nothing. The other channel processes the message and sends ACK in postprocessor.
There are other options, say, on System B side redirect an incoming message to another channel which forms Ack and sends it back to System A, but then System A should have a listener on its side.
Or, System B may have a receiving channel that sends Ack immediately, routes the message to another channel that is connected to its destinations, and remove that destination to prevent incoming message to propagate to that channel. The second channel processes the message and sends Ack back to the first channel. First channel resends that Ack back to System A. (I have not tested such configuration, so this is just an idea to overcome a single responseMap. It may not work.)
in xmpp publish subscribe protocol there is a provision to subscribe and unsubscribe to a node. but what if a publisher itself want to temporarily unsubscribe some of the subscribers and keep on publishing to selected subscribers only.
for example
A , B and C has subscribed to node PIZZA now if after somepoint if PIZZA node wants to publish only to A and C but not B.
i read the protocol but i didn't find anything like this , so is there anyone has any idea how to do it ?
i am using openfire as server and asmack libs as client
I don't know much about xmpp, maybe this is standard practice there, but normally the publisher doesn't know anything about the receivers so shouldn't control who is subscribed. Why does the publisher know better than the receiver whether the receiver should receive?
I would try a different approach, such as adding data in the message so the receiver can decide whether they should ignore the message.
Sending a blank message would not likely work: then all receivers that handle message only if not blank will skip it. So it will only work if B does not filter on blank messages. Instead, if the message has "filter=...", then receivers can decide to process based on the value of filter. Like, perhaps receivers A and C are a Type "X" of receiver, and receivers B and D are a type "Y" of receiver. Then if filter = "X", then receivers B and D know to ignore it. If filter is "Y", A and C know to ignore it. If filter is empty, they all process it.