I would like to know if the handshake protocol is synchronous or asynchronous. I heard the is also called the synchronization protocol,but i don't know synchronous or asynchronous.
Related
How can I abort the HTTP Request and not close the connection while implementing a netty HTTP client?
At the moment I am using NioSocketChannel and I am confused if doClose is the only option.
Is there a more generic way of canceling the request, that can work with any kind of socket channel, eg KQueue?
Netty's ChannelFuture extends the netty Future which provides a cancel method: https://netty.io/4.0/api/io/netty/util/concurrent/Future.html#cancel-boolean-
I'm pretty sure that's what you're looking for.
doClose closes the channel where a channel is described as "A nexus to a network socket or a component which is capable of I/O operations such as read, write, connect, and bind." So that would close the connection, as you're seeing. It doesn't look like that's going to help you.
I was reading various resources about netlink, and they all say that the netlink communication protocol is asynchronous (example: https://www.opensourceforu.com/2015/08/netlink-a-communication-mechanism-in-linux/), however this confuses me: I think only events notification mechanism of netlink is asynchronous, while request messages are sent/received synchronously.
Am I wrong?
This is not about asynchronous client-to-server call.
It's about a gRPC server programming model. To maximize the gRPC server throughput, it's desired that a gRPC server delegates received requests to non-gRPC threads with a callback for each request. When non-gRPC threads get things done, they inform the gRPC server to response gRPC clients by calling equipped callbacks for these asynchronously handled requests.
Is this possible for grpc? I noticed there is an experimental feature about callback mechanism. However, an experimental feature is not a choice for my projects.
Or, in another words,
1) how could a gRPC server thread not be blocked by time-consuming request handling?
The C++ server has two threading models available: sync and async. Most users will want to use the sync model: the server will have an (internal) threadpool that manages multiplexing requests onto some number of threads (reusing threads between requests). The async model allows you to bring your own threading model, but is a little trickier to use - in that mode you request new calls when your server is ready for them, and block in completion queues while there is no work to do. By arranging when you block on the completion queues, and on which completion queues you make requests, you can arrange a wide variety of threading models.
https://groups.google.com/g/grpc-io/c/Cul6fd7cOB0/m/c5gndkNpGQAJ has detailed discussion about both sync/async server models.
I need asynchronous message sending. I read about non-blocking sending on MPI (e.g. MPI_Isend or MPI_Ibcast) and functions to wait/test that sending request (MPI_Wait*/MPI_Test*). However I realize (through testing and web info) that non-blocking send might never get progress on receiver unless that sender invokes functions MPI_Wait*/MPI_Test* after it sends. How can I get a real (and optimal) asynchronous sending?
Regards
Does the MPI standard implement the request-reply communication pattern?
Reading about MPI I found that there are point-to-point routines like:
Synchronous send
Blocking send / blocking receive
Non-blocking send /non-blocking receive
Buffered send
Combined send/receive
"Ready" send
Maybe a developer can implement the request-reply communication pattern using these routines, but it seems that MPI does not directly implement it.
Edit: For clarifying purposes the request-reply (request-response) is a message exchange pattern in which a requestor sends a request message to a replier system which receives and processes the request, ultimately returning a message in response. This is a simple, but powerful messaging pattern which allows two applications to have a two-way conversation with one another over a channel. This pattern is especially common in client–server architectures. It may be synchronous or asynchronous.
This is not available as-is.
That being said, this is trivial to implement.
The requestor can MPI_Sendrecv() and the replier can MPI_Recv() the request and then MPI_Send() the answer.