I want to implement a protocol stack with netty
on the low level there is only one long lasting channel connecting the client and the server
but at one layer above, this channel is used by multiple clients.
Is there a way to open a new channel object in Netty that will deal with each client of the upper layer in an elegant manner ?
Looking forward to hearing form you guys
Netty not know about your layer on top and just provide you with the Channel. You can use this Channel from multiple threads but how you do use it is up to you.
Related
gRPC requests in .NET rely on channels, that must be shut down and disposed:
using var channel = Grpc.Net.Client.GrpcChannel.ForAddress("path to service");
//...do stuff...
await channel.ShutdownAsync();
I'm wrapping this in a .NET dependency injected service using IServiceCollection, should this be...
Per-method - create and dispose the channel inside each method call.
AddTransient - a new channel every time my service is requested, but only as long as it's needed.
AddScoped - a new channel for each request, but keeping the channel open until the request is done.
AddSingleton - a single new channel for the app.
I think AddSingleton is out as I'm not sure how one GrpcChannel will handle lots of parallel requests at the same time and I'd like to pass the CancellationToken for the current request.
Which puts the choice between AddScoped vs AddTransient vs per-method. Without a load of testing (and stumbling into all the pitfalls) I'm not sure what the best practice here is (I'm new to gRPC). Should I be closing the channel as soon as possible, or keeping it open and sharing it between calls?
According to Microsoft
https://learn.microsoft.com/en-us/aspnet/core/grpc/client?view=aspnetcore-5.0#client-performance :
A channel represents a long-lived connection to a gRPC service.
and
Channel and client performance and usage:
Creating a channel can be an expensive operation. Reusing a channel for gRPC calls provides performance benefits.
gRPC clients are created with channels. gRPC clients are lightweight objects and don't need to be cached or reused.
Multiple gRPC clients can be created from a channel, including different types of clients.
A channel and clients created from the channel can safely be used by multiple threads.
Clients created from the channel can make multiple simultaneous calls. need to be cached or reused. Multiple gRPC clients can be
created from a channel, including different types of clients. A
channel and clients created from the channel can safely be used by
multiple threads. Clients created from the channel can make
multiple simultaneous calls.
According to grpc https://grpc.github.io/grpc/csharp-dotnet/api/Grpc.Net.Client.GrpcChannel.html :
Class GrpcChannel Represents a gRPC channel. Channels are an
abstraction of long-lived connections to remote servers. Client
objects can reuse the same channel. Creating a channel is an expensive
operation compared to invoking a remote call so in general you should
reuse a single channel for as many calls as possible.
As always, it depends on what you are trying to do, but probably only single channel should be created by a Singleton. Also, if you really need to handle a heavy load, try using SocketsHttpHandler.EnableMultipleHttp2Connections (https://learn.microsoft.com/en-us/aspnet/core/grpc/performance?view=aspnetcore-5.0#connection-concurrency)
Grcp clients should be registred with the GrcpClientFactory
builder.Services.AddGrpcClient<Greeter.GreeterClient>(o =>
{
o.Address = new Uri("https://localhost:5001");
});
(Surprisingly, this registers them as transient)
See:
https://learn.microsoft.com/en-us/aspnet/core/grpc/clientfactory?view=aspnetcore-6.0
Just asking one silly question, hope someone can answer this.
I'm bit confused regarding MQTT broker. Basically, the confusion is, there are so many things being used for data storing, transfer and processing (like Flume, HDInsight, Spark etc). So, when and why I need to use one MQTT broker?
If I would like to use Windows 10 IoT application with HiveMQ, from where can I get the details? how to use it? How I get benefit out of this MQTT broker? Can I not send data from my IoT application directly using Azure or HDFS? So, how MQTT broker fits into it or helping me to achieve something?
I'm new to all these and tried to find some tutorials, however, I'm not getting anything proper. Please explain it in more details or give some tutorials for this?
MQTT is a client-server protocol for pub-sub based transport that has a comparatively small overhead, and thus applicable to mobile and IoT applications (unlike Flume, etc.). The MQTT broker is basically a server that handles messaging to/from MQTT clients and among them. The functionality pretty much stops at the transport layer, even though various MQTT add-ons exist.
If you are looking to implement a solution that would reliably transfer data from your IoT devices to the back-end system for processing, I would suggest you take a look into Kaa open-source IoT platform. It goes much further than MQTT by providing not only the transport layer, suitable for low-power IoT devices, but also a solid chunk of the application level logic (including the object bindings for your application-level data structures, temporary data persistence, etc.).
Here is a link to a webinar that explains how to build a scalable IoT analytics system with Kaa and Spark in less than an hour.
This is an architectural choice. IoT applications are possible without MQTT but there are some advantages when using MQTT. If you are completely new to MQTT, take a look at this in-depth MQTT series: http://forkbomb-blog.de/2015/all-you-need-to-know-about-mqtt
Basically the main architectural advantage is publish / subscribe designed for low-latency, high throughput (mobile) communication with minimal protocol overhead (which is important if bandwidth is at a premium). You can completely decouple consumers and producers.
HDFS is the (distributed) Hadoop file system and is the foundation for Map / Reduce processing. It is not comparable to a MQTT broker. The MQTT broker could write to the HDFS, though (in case of HiveMQ with a custom plugin).
Basically MQTT is a protocol while the products you are mentioning are, well, products which solve completely different problems:
Flume is basically used for log aggregation at scale. You won't use MQTT for that, at least there is not too much advantage because this is typically done in backend applications.
Spark and Hadoop shine at Big Data crunching. They are a framework and not a ready to use solution. They are not really comparable to MQTT. Often MQTT brokers like HiveMQ are used in conjunction with these, Spark / Hadoop for data processing and HiveMQ for communication.
I hope this helps you getting started. Best would be to read about typical use cases of all these technologies, this is a bit too broad for a single SO answer.
MQTT is a data transport, so the usual thing I have to compare it with is HTTP. HTTP has two important characteristics, a) It goes from one point to another, b) It is request/response, so only one end can start a data transfer. MQTT connects many end points to many end points, and either end can start a data transfer. So, if you have just one device and only one service or person that will ever access it, and only by polling, then HTTP is great. MQTT means many devices can post data to many services or people, AND the other way around. Your question assumes that your data is always going to land up in some sort of data store, but many interactions are about events and responding to them immediately, like ringing a doorbell, or lowering the landing gear. In these cases you will often want to both record the data, and have an immediate action occur, like your phone making a doorbell noise.
Finally, you send data to MQTT semantically, rather than by IP address.
This means that your services subscribes to /mikeshouse/doorbell rather than polling 192.168.22.4, which is a huge gain once you have a number of devices.
http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-M2/scala/stream-integrations.html says:
"ActorPublisher and ActorSubscriber cannot be used with remote actors, because if signals of the Reactive Streams protocol (e.g. request) are lost the the stream may deadlock."
Does this mean akka stream is not location transparent? How do I use akka stream to design a backpressure-aware client-server system where client and server are on different machines?
I must have misunderstood something. Thanks for any clarification.
They are strictly a local facility at this time.
You can connect it to an TCP sink/source and it will apply back-pressure using TCP as well though (that's what Akka Http does).
How do I use akka stream to design a backpressure-aware client-server system where client and server are on different machines?
Check out streams in Artery (Dec. 2016, so 18 months later):
The new remoting implementation for actor messages was released in Akka 2.4.11 two months ago.
Artery is the code name for it. It’s a drop-in replacement to the old remoting in many cases, but the implementation is completely new and it comes with many important improvements.
(Remoting enables Actor systems on different hosts or JVMs to communicate with each other)
Regarding back-pressure, this is not a complete solution, but it can help:
What about back-pressure? Akka Streams is all about back-pressure but actor messaging is fire-and-forget without any back-pressure. How is that handled in this design?
We can’t magically add back-pressure to actor messaging. That must still be handled on the application level using techniques for message flow control, such as acknowledgments, work-pulling, throttling.
When a message is sent to a remote destination it’s added to a queue that the first stage, called SendQueue, is processing. This queue is bounded and if it overflows the messages will be dropped, which is in line with the actor messaging at-most-once delivery nature. Large amount of messages should not be sent without application level flow control. For example, if serialization of messages is slow and can’t keep up with the send rate this queue will overflow.
Aeron will propagate back-pressure from the receiving node to the sending node, i.e. the AeronSink in the outbound stream will not progress if the AeronSource at the other end is slower and the buffers have been filled up.
If messages are sent at a higher rate than what can be consumed by the receiving node the SendQueue will overflow and messages will be dropped. Aeron itself has large buffers to be able to handle bursts of messages.
The same thing will happen in the case of a network partition. When the Aeron buffers are full messages will be dropped by the SendQueue.
In the inbound stream the messages are in the end dispatched to the recipient actor. That is an ordinary actor tell that will enqueue the message in the actor’s mailbox. That is where the back-pressure ends on the receiving side. If the actor is slower than the incoming message rate the mailbox will fill up as usual.
Bottom line, flow control for actor messages must be implemented at the application level. Artery does not change that fact.
We are trying out an option of having multiple parallel thread meaning multiple consuming for different set of keywords by establishing single connection. Is it possible or should we establish new connection if we want to consume another set of data? Can anyone guide on this
Regards,
Balaji D
This is documented on DataSift's Multiple Streaming docs page. Some of the official API Client Libraries also support multi-streaming over WebSockets.
1)
Now I am writing IM chat System i face some problem how to send vector that has information from the server to Client
2)
is any way to communicate between tow client ??
I Use CBC2010 - Indy10
Basically communicating over TCP is about sending bytes from client to server, and receiving bytes on the client from the server.
You either can give meaning to those bytes, or have something wrap that for you.
There are many possibilities and protocols to choose from.
On the foundation, you have either UDP (which is unreliable, but incurs almost no overhead, but very well suited for broadcasts) and TCP (which is more reliable, therefore has more overhead, but is easier to use).
A transport protocol that is often used on top of TCP is HTTP, especially since it is easy to get it through proxy servers.
On top of that you can do XML+SOAP or JSON+REST, which make translating from/to your underlying objects a lot easier.
All in all there are a truckload of options to choose from.
A simple start is the Delphi chat example at delphi.about.com. That definitely should get you going.