I have to implement a communication protocol stack in C. There exists already an outlining design. The stack consist of 3 layers (connection-control, security, fragmentation). The functionality of these layers is not relevant here. The idea is, that each layer processes an incoming/outgoing telegram according to its responsibility and hands it to the next layer in the stack. I thinks that’s the usual idea of a stack.
My question is, what a good design is and how are the dependencies of the various items of each layer.
I have thought of two approaches:
A chain like implementation:
For an incoming telegram, a process-in data function of the connection control item is called by a preceding item (not in the scope of this post). Then the connection control does something with the telegram and then calls the security items process-in data function, then the security item does something and forwards the telegram to the fragmentation item. The same idea applies for outgoing telegrams, in a reversed direction by calling process-out data functions.
A central control item implementation:
In this approach a central control gets the an incoming telegram, it then calls the process-in data function of the connection-control which returns the telegram after doing something. Then the central control item calls the process-in data function of the security item and so on.
Maybe this central control item could be implemented as a state-machine, where each state represents one of the communication protocol layers mentioned above.
Related
I have a system, connected to financial markets, that makes a very heavy use of events.
All the code is structured as a cascade of events with filters, aggregations, etc in between.
Originally the system was written in C# and then ported to F# (which in retrospect was a great move) and events in the C# code got replaced by events in F# without giving it much thoughts.
I have heard about the observer pattern, but I haven't really gone through the topic. And recently, I have read, through some random browsing, about F#'s Mailbox processor.
I read this: Difference between Observer Pattern and Event-Driven Approach and I didn't get it, but apparently over 150 people voted that the answer wasn't too clear as well :)
In an article like this: https://hackernoon.com/observer-vs-pub-sub-pattern-50d3b27f838c it seems like the observer pattern is strictly identical to events...
At first glance, they seem to be solving the same kind of problems, just with different interfaces but that got me to think about 2 questions:
Is the mailbox processor really a thing being used? it seems to appear mostly in older documentation and, in the packages I'm using, I haven't come across any using it
Regarding the observer pattern, only one package across the sizeable amount we're using makes internal use of it, but everything else is just using basic events.
Are there specific use cases fitting the Observable pattern and the MailboxProcessor? Do they have features that are unique? or are they just syntactic help around events in the end?
As simplified as possible:
Mailbox
This is a minimal implementation of the actor model.
You post messages to a queue, and your loop reads the messages from the queue, one by one. Maybe it posts to another mailbox or it does something with the messages.
Any action can only take place when a message is received.
Posting to the queue is non-blocking, i.e, no back-pressure.
All exceptions are caught and exposed as an event on the mailbox. They are expected to be handled by the actor above it.
Other actor frameworks provide features like supervisors, contracts, failover, etc.
Events
Events are a language supported callback mechanism.
It's a simple implementation. You register a callback delegate, and when the event is raised, your delegate is called.
Delegates are called in the order they are added.
Events are blocking, and synchronous. The one delegate blocks, the rest are delayed.
Events are about writing code to respond to events, as opposed what came before it, which was polling.
The handler for an event is usually the final end-point for that event, and it usually has side-effects.
Sharing a handler is common. For example, ten buttons might have the same function handling clicks, because the sender of the event is known.
You handle exceptions by yourself, typically in the handler code
Observables
There's a source (Observable) which you can subscribe to with a sink (Observer). An observable represents a bounded or un-bounded stream of values. An unbounded stream (an Observable which never completes) seems similar to an event, but there are several important properties to Observables.
An Observable emits a series of notifications, which follows this contract:
OnNext* (OnError|OnCompleted)+
All notifications are serialized
Notifications may or may not be synchronous. There's no guarantee of back-pressure.
The value of Observables lies in the fact that they are compose-able.
An observable represents a stream of future notifications, operators act to transform this stream.
This approach is sometimes called complex event processing (CEP).
Exception handling is part of the pipeline, and there are many combinators to deal with it.
You typically never implement an Observer yourself. You use combinators to set up a pipeline which models the behavior you want.
I have some complex networking in my app( I don't use any third party dependencies, because of project requirements). For instance, I send three network requests in parallel after first two requests provide results. All my networking is done in separate models, known as networkClients(following MVC-S pattern) and are called directly from repository, not from ViewControllers. However, I need the last request to notify my viewController after I get response from network. How should I do that? I don't think notification center would be right solution because it can cause memory leaks and I have not found correct approach to complex problem like this. Please provide some prominent solutions. It should conform to good design pattern like MVVM or MVC and should not be some workaround or hack. Maybe delegates would work? I know that rxSwift would solve my issue, because I could start observing for results after initializing viewController and after data would be updated from repository my viewController would also be notified...
The right design doesn't have VCs observing the network clients directly. Those network operations should be assembling parts of a model, which is what the VC really cares about. Have the VC observe that singular model.
It can do this observing using one of the well known patterns for loosely coupled communication between objects. The OP correctly mentions delegates. Notification center and KVO are others. There's plenty of discussion on SO about which to use and how to implement. (I'd go with NSNotificationCenter as an easy and rational start).
So the order of operation is like this:
allocate the model
launch the network requests and setup those request completions (completion blocks, probably) to update that model with their responses. (the model can launch the requests, which is a reasonable practice).
create the view controller(s) that setup model observation when they initialize (probably, in viewWillAppear or later)
What about the fact that >1 requests are in flight simultaneously? A commenter above points out correctly that GCD offers a way to group those async operations into a single one. But you can do this yourself straight-forwardly: the model decides when it's completely built. The completion code for each request will change some condition in the model to the "ready" state. Each request completion can check to see whether all of the ready conditions are met, and only then post a "ready" notification for observers to see.
Another niggling issue: what if those requests all run very, very fast? Maybe there's some cached response that's ready early, making the model "ready" before the VC has had a chance to setup observation? Handle this straight-forwardly in the VC: before observing the model, check to see if it's ready already and run the same update code that runs on the notification.
Say we want to make an application containing the following:
Asynchronous and time consuming operations on selected objects
For a certain object we want to access the status of an associated operation.
The ability to show, cancel and pause these operations from multiple views.
Then my question is the following:
Where do these operations and their progress/status belong in an Application Design Pattern?
To put it into context here is a dummy application:
Example Application:
We have an application where you can apply different Filters to Images. Application consists of a Directory View and Detail View.
Each filter can be applied asynchronously to any image from each view.
The filter-operation can be observed and canceled from both views.
A filter operation can not be started if there is already one initiated for that filter-type and image, or if such a filter has already produced a result.
In this dummy application the views are subsequent, but in the general case you would not be able to pass information directly between the views.
Progress
Decoupling the Service Layer or Network Controller from the View and Model in a design pattern like MVC or MVVM is quite straight forward, as long as you don't provide more UX feedback than a spinner when there's an active network request.
But when I am working on an application confirming to the criteria above, I always end up either
Not allowing the user to change view during an operation
Tagging operations with the id of the object currently processed and passing this to the views, or looking in the Network Controller directly from the views/view controllers
Creating a separate entities for operations, and suddenly I have a request operation in my model
So obviously there are (very smelly) ways to come around this, but they all feel dirty and not inline with how the patterns are intended.
So purely from a software architecture and design pattern point of view, how would you approaching this?
I generally prefer a promise object for this design issue. The promise object can contain methods to cancel the operation, check on the status of the operation and even contain closures to be executed depending on what happens with the operation (success, failure, cancel, etc.).
That promise object can either be handed from view to view or can be served from the network layer upon multiple requests (view A kicks off operation, view B tries later to kick it off but it is already running so gets the same promise object).
That means that the service layer, or network layer in this case, needs to present which operations, requests, are ongoing for which object, right? Because you don't want to kick of a request just to get the promise object, in case a button should be hidden if the operation is already started. I guess you would keep these promise objects outside your app model since they don't live between sessions, and the network layer would store them by url, but how would you generally serve this back from the network layer without exposing to much the network layer to the ui?
Network layer has convenience methods for the UI to utilize to kick off requests that the user initiates. The network layer determines if a request has already started and returns the same promise. Even if the network layer kicked off the process internally (auto refresh, etc) it can still deliver the promise back to the UI if the UI tries to start the same process.
The promise objects only live as long as the operation is on-going. I actually have the operation be the true holder of the promise object and the network controller holds the queue of operations. Then when a request comes in, I search the queue for the existence of that operation and if it exists return the promise from the operation. If it doesn't exist, I create a new operation, put it in the queue and return its promise object.
The interface between the UI and the back end is the exposed methods on the network controller. The UI has no knowledge of operations, it just has a function that says "go refresh this or go get that" and gets a promise back. It does not need to know or care how the job is performed, it just knows that the promise is its way to check on the status of that operation.
Now, if it is a data refresh, then the promise isn't needed for data updates, the NSFetchedResultsController will handle that. The promise in that situation handles "am I active" and "cancel me" type requests only.
There will be many ways to do this. But here's an idea... Maybe you can use messaging as style: define a "status" channel, possibly use a pub-sub model for getting the status/progress of on-going operations. So that way, the process performing the operations publishes the status on a channel, and your multiple views subscribe to that channel and display the status. Now, if you have to cancel/pause operations, you possibly need to have another control channel. You do have to manage concurrency, order etc.
I am building a remote app which is receiving different states of its accessory. It is receiving things like: power state on/off, volume state 5, equalizer setting jazz, etc. and has nothing more to do than map theses states into the UI with selected or unselected states and send changes done back to the accessory.
About the app architecture:
The app is connected with it's accessory as illustrated in Apples EADemo project using the external accessory framework.
The UI is build within non-repeating customized UITableViewCell full of UIButtons. When starting the app a data model class will receive all current states from the examples EADSessionController and has to communicate theses states to the UI (the cells directly rather than the UITableViewController) with one of the mentioned patterns. This will be a stand alone, one-page app looking like a real remote.
Thinking of NSNotification, delegates and KVO (key-value-observing) I am trying to figure out which of these patterns I should use for this special approach?
Any answer on why choosing one of them and a brief description on how to implement would be appreciated. If your answer will be KVO please give some more insights since I never used this pattern so far.
It really depends.
The most loosely coupled one is to use NSNotification and NSNotificationCenter, as the instance which post the notification does not necessarily have knowledge about the observer, and there can be more than one observer.
The delegate pattern is a little more rigid, and there could usually be only one delegate object that receives a message. If the UITableViewController in your project is the only instance that handles a message(, or it would properly propagate the message to other components), it is still OK.
The KVO pattern requires more precisely designed observation relationship. You will have and have to look after exactly how the KVO is implemented. And KVO also allows one-to-many observation. The down side of KVO is if the observing relationship is dynamic and transient, you must take much more care about how these objects were torn down, or you could get a lot of crashes like sending updates to a dealloc'ed instance, etc.
If you are working on a library which would be delivered to a 3rd party to use, perhaps NSNotification would be the first choice.
This question describes two approaches of solving the sophisticated architectural problem related to ASP.NET MVC. Unfortunately our team is quite new to this technology and we haven’t found any solid sources of information on this particular topic (except overviews where it’s said that MVC is more about separation than componentization). So as for now we are hesitating: whether our solution is appropriate or there is a different obvious way to solve this problem.
We have a requirement to make ASP.NET MVC-based design with componentization in mind. View engine Razor is also a requirement for us. The key feature here is that any level of controller’s nesting is expected (obviously thru Html.Action directive within .cshtml). Any controller could potentially obtain the data thru a webservice call (the final design can break this limitation, as it’s described below).
The issue is that the data must be obtained in async and maximum parallel fashion. E.g. if two backend calls within the controllers are independent they must be performed in parallel.
At first glance the usage of async MVC controllers could solve all the problems. But there is a hidden caveat: nested controller must be specified within cshtml only (within a view). And a .cshtml view is being parsed after the original controller finished its own async execution. So all the async operations within the nested controller will be performed in a separate async slot and therefore not in parallel with the first parent controller. This is a limitation of synchronous nature of .cshtml processing.
After a deep investigation we revealed that two options are available.
1) Have only one parent async controller which will retrieve all the data and put this data into container (dictionary or whatever). The nested controllers aren’t allowed to perform any backend calls. Instead of this they will have a reference to the initialized container with the results of all the backend calls. Bu this way the consumer of the framework must differentiate between parent and child controller which is not a brilliant solution.
2) Retrieve all the data from backends within a special async HttpModule. This module will initialize the same container which will reside, for instance within HttpContext. Obviously all the controllers in such a case will not be allowed to perform any backend calls, but they will have a unified internal structure (in comparison with #1 option).
As for now we think that the option #2 is more desirable, but we are more interested in the solid community-adopted way to solve this problem in a real enterprise-level MVC projects.
Literally any links/comments are welcomed.
[UPD] A requirement of any level of nesting of controllers came from our customer which wants a system where fully reusable MVC components will be presented. And they could be combined in any sequence with any level of nesting - as it is already done in the existing webforms-based implementation. This is a business rule for existing app that the components could be combined anyhow so we're not targeted to break this rule. As for now we think that such a component is a combination of "controller+view+metadata" where "metadata" part describes the backend calls to be performed in the scenario 1 or 2.
Why are you considering async calls here? Keep in mind if your async calls are so the asp.net threads don't get all used up since the db is taking a while to return, as soon as new requests come in they too will go to the db, thus increasing the workload and in turn gaining nothing.
To be honest though, Im having a hard time following exactly what you have in mind here. Nested controllers for...?
"The key feature here is that any level of controller’s nesting is expected"
I think I (we?) need a bit more information on that part here.
However, the warning on async still stands :)
E.g. if two backend calls within the controllers are
independent they must be performed in parallel.
If they are truly independent you might be able to use asynch JavaScript calls from the client and achieve some degree of parallelism that way.