I am currently testing a Diameter protocol receiving component using Seagull to send my Diameter messages.
I have realised I am having to manually kill the Seagull process as it is expecting a response back when the Diameter message has been received by the system under test and this is not something the system is set up to do.
before I look to change the way I send my messages to work around this issue I wanted to check if the standard process for Diameter protocol is to send a response on receipt of a message and therefore is this a requirement that has been missed during design.
Im not familiar with a Diameter interface that includes Request without answer and I doubt if such exist since the protocol includes a lot of parameters that support request/answer mechanism (r-bit, hop-by-hop,end-to-end, Session-Id AVP....) how ever there are dozens of interfaces of Diameter so please share the interface you work with (For example: Ro,Gy,Gx,S6a...)
Regarding your Seagull case:
Seagull can only send and does not have to receive. Check where you have "receive channel" in your scenario XML. This where Seagull waits for answer. Remove it and you have a Seagull that only sends.
Every correct Diameter negotiation starts with request (CER) and Answer (CEA). If you want to simulate a full correct flow your Seagull will have to wait for answers
Related
I'm creating a chat application, and one detail is that "acknowledgements" are crucial. I'll get to what that means. I'm trying to figure out what the best exchange protocol would be.
Scenario:
Alice sends Bob a message. Bob is offline, so the message is stored on the server. Bob connects to the server through a WebSocket connection. The server sends him messages that have been sent to him while he was away. This is where the problem arises. The WS API that's available for my app's ecosystem (Node.js, Nest.js specifically), has no pattern where it can wait for this message to be sent. The mechanism there seems to just be fire & forget. What if the payload is quite large and the connection drops while the message is being sent?
Now, I know socket.io has support for acknowledgements. But from what I've read, socket.io has some overhead and therefore less performance than optimal. Now whether that performance is something that I arguably need is another question, but I'm just trying to figure out how I can guarantee that the message has arrived on the other end. This means client-server and server-client directions. How can I await it? I know that one approach is to attach a unique ID to the socket event, and have the other side send you a confirmation that it received it. This is how socket.io does it if I'm not mistaken.
But my question there is how can I guarantee that the acknowledgement message was successfully sent? So then I'd need an "ack" for my "ack" and so on, so I'll always need one more acknowledgement so I don't know how that works.
What I though of as options is to use two REST endpoints to send and receive (or download) messages. You send when you send, but you receive when you receive a ping that there's messages for you to download. Now this could be done through a WebSocket connection where the server notifies the client about a new message and then the client can call this receive endpoint. This ping can also be done through a more managed solution like FCM. The pros with that approach are twofold:
First, I have the REST interface to use, which is a lot more practical
I have the Request-Response pattern to use, so I have a theoretical guarantee that things are arriving if I get a response
Now the problem with this approach is that there's a lot of overhead from opening a new HTTP connection every time I want to send or receive messages, if I'm not mistaken:
I have to wait for the initial request time to get to the server before I actually have to wait for the server to respond with messages. With the pure WebSockets case, I would theoretically then just wait for the response equivalent part there (?)
This wastes bandwidth as well.
So one more question, where can I find out which clients will actually re-use an existing HTTP connection like a WebSocket connection, if available and not create a new one? Do all clients do that? Is it only the browser? What about apps? Is it on the OS level?
So the final question is how do I solve this problem of "acknowledgements" and not waste time and bandwidth? Are any of my conclusion/questions wrong or uninformed, am I missing something?
Notes:
server is Node.js and client is Flutter
i know about the WAMP subprotocol, but for my ecosystem it doesn't have very reliable implementations
I'm not sure what your exact requirements or performance need,
but I did a project that also need reliable communication between client and server using websocket, the simplest I could think of was build request-response mechanism on top of websocket, and then build your application data on top of that.
here's high level overview how I implemented it:
implement request-response message using transaction to identify which response belongs to which request.
clients will have map storing transaction, when you send the message request wait for server to send a message response with the same transaction or wait
until timeout.
client wants to send message to server and construct the request as follow
{
"event": "sendMessage",
"type": "request",
"transaction": "<uuid/unique-value>",
"data": "<your-application-data>"
}
server parse the message and check that its a request with an event name sendMessage then call related function
server sends back response message to client
{
"event": "sendMessage",
"type": "response",
"transaction": "<uuid/unique-value>", // same unique value as in request
"data": "<your-application-data-result>"
}
because client has mapping which transaction belongs to which request, it is possible to match which request this response belongs to, if matched then complete the transaction
I am evaluating MessageBird service. I got a Virtual Mobile Number. I am able to send message to dummy numbers (until i get approval for sending messages to real USA number)
Unknown: My problem is about reading the messages received by a VMN.
Details: If I as a VMN owner send a message to consumer e.g. +1(111)111-1111 and i am interested in reading the response from the consumer, how to do get it?
MessageBird documentation expects me to know the ID for response message object (or my understanding is wrong). The documentation is good but i don't see a way to programmatically achieve it. Any suggestions How to achieve it?
Thanks in advance!
Messagebird have a feature of forward incoming sms data through webhook(get or post method). if you set an url then Messagebird will forward every incoming sms to you(or your server). You can easily read get/post response.
My HTTP server needs to make sure that HTTP responses are delivered to the client.
I feel (and I will implement it so) that the most correctly way is to send the "I received the data" request from the client.
But I have a bit academic question:
Has the server some other means to detect whether the response delivered to the client or not (say due to the client's computer was evaporated by a direct hit of an H-bomb during data transmission)?
According to the node.js http documentation:
Class: http.ServerResponse
...
Event: 'finish'
Emitted when the response has been sent. More specifically, this event
is emitted when the last segment of the response headers and body have
been handed off to the operating system for transmission over the
network. It does not imply that the client has received anything yet.
After this event, no more events will be emitted on the response
object.
Also I did not find nothing better in the 'net' module documentation.
So it seems I can only know that my data is in the kernel buffer for transmisstion over the network.
Can I detect some errors at this transmission by Node.js means?
Can I detect some errors at this transmission by some easy-to-implement non-Node.js means?
Any links and thoughts that this is not an HTTP way or even not a TCP way are also appreciated.
The thing about TCP is that the receiver must acknowledge the fact that it receives every single bit of data. If that's not the case, sender keeps sending the pieces of data that receiver has not yet acknowledged to receive.
I checked out the Net module and I saw this interesting piece:
Event: 'end'
#
Added in: v0.1.90
Emitted when the other end of the socket sends a FIN packet.
I have no implementation idea for this but still, this might be useful for your case.
I have a web based multiplayer game. It happens from time to time that someone is kicked out because server did not get expected message from client. It seems from my logs that client did not disconnect, just did not send message or server did not receive it. My question here is "Does this things happen normally from time to time?" Should i use some kind of callback mechanism to ensure message is delivered and if not send it again or is there some issue that i am not aware?
socket.io already provides ACKs and message ID tracking, on top of TCP.
Also, socket.io uses pings to check the connection. So, if you say that the client is not disconnected, and the server tells that the client is not disconnected, then the connection is still there.
The problem must be situated elsewhere.
Are you sure there is not a bug in either part of the implementation? Showing some code snippets could help, as well as the environment you are using.
small question. How can I calculate the ping of a WebSocket connection?
The server is set up using Node.js and node-websocket-server, if that matters at all.
There is few ways. One that is offered by Raynos - is wrong. Because client time and server time are different, and you cannot compare them.
Solution with sending timestamp is good, but it has one issue. If server logic does some decisions and calculations based on ping, then sending timestamp, gives risk that client software or MITM will modify timestamp, that way it will give another results to server.
Much better way, is sending packet to client with unique ID, that is not increment number, but randomized. And then server will expecting from client "PONG" message with this ID.
Size of ID should be same, I recommend 32bits (int).
That way server sends "PING" with unique ID and store timestamp of the moment message sent, and then waiting until it will receive response "PONG" with same ID from Client, and will calculate latency of round-trip based on stored timestamp and new one on the moment of receiving PONG message.
Don't forget to implement case with timeout, to prevent lost PING/PONG packet stop the process of checking latency.
As well WebSockets has special packet opcode called PING, but example from post above is not using this feature. Read this official document that describes this specific opcode, it might be helpful if you are implementing your own WebSockets protocol on server side: https://www.rfc-editor.org/rfc/rfc6455#page-37
To calculate the latency you really should complete the round-trip. You should have a ping message that has a timestamp in it. When one side or the other receives a ping it should change it to a pong (or gnip or whatever) but keep the original timestamp and send it back to the sender. Then the original sender can compare the timestamp to the current time to see what the roundtrip latency is. If you need the one way latency divide by 2. The reason you need to do it this way is that without some very sophisticated time skew algorithms, the time on one host vs another is not going to be comparable at small time deltas like this.
Websockets have a ping type message which the server can respond to with a pong type message. See this for more info about websockets.
You can send a request over the web socket with Date.now() as data and compare it to Date.now() on the server.
This gives you the time difference between sending the packet and receiving it plus any handling time on either end.