Can someone please provide links to any paper/reference that talks about disconnected components in P2P networks?
I have found this paper. It deals with various P2P networks including kademlia which is the basis of bittorent DHT. It defines a probabilistic metric called routability rather than talking about connectivity but I guess the two things are related. (With high routability the graph is probably connected.) From the paper:
... we consider the measure of
routability, which is defined as the
expected number of routable node pairs
divided by the number of possible node
pairs among the surviving nodes. ...
(source: imagehost.org)
One paper calls it the islanding problem, another calls it isolated overlays.
Related
I'm modelling an activity diagram for a project. Directly after initial node is it okay to use a decision node. I just google for it. But I fail to find similar examples even.
Eg:- imagine a person can Search for a dog name or Select the category animal, then dog likewise at the very beginning.......
One of my team mates mention that according to above example those are two different activities and we should create two activity diagrams for it.
This is allowed under condition.
The rules concerning the input flow(s) of a decision node are (formal 2017 § 15.3.3.6 Decision Nodes page 390) :
A DecisionNode shall have at least one and at
most two incoming ActivityEdges, and at least one outgoing ActivityEdge. ... If the DecisionNode has only one
incoming edge, then it is the primary incoming edge. If the primary incoming edge of a DecisionNode is a ControlFlow,
then all outgoing edges shall be ControlFlows and, if the primary incoming edge is an ObjectFlow, then all outgoing edges
shall be ObjectFlows.
Also knowing (§ 15.3.3.1 Initial Node page 387) :
The outgoing ActivityEdges of an InitialNode must all be ControlFlows.
that means in your case, and supposing there is no other input edge to the DecisionNode, all outgoing edges of the DecisionNode shall be ControlFlows, else this is not allowed
Your team mate isn't wrong. This is a design question which should have been clarified beforehand. Activities are functional parts inside of use cases. They represent scenarios like "sunny day", various error scenarios, etc. And again one step back the use cases represent the added value the system under consideration represents for its primary actor.
Now from your examples it's hard to tell what that system should be. Search for dog name could be a use case, but in which context? Is it to name a new dog or to search for an existing dog in a database? Same for Select animal category(and then dog?). Both do not make much sense as use cases. Once you come up with meaningful use cases you can tell exactly which steps the activities should have as actions. Only then you can have the need to decide. The decision which use case to actually use it outside the system and you wont see the steps done for it.
As a recommendation: Bittner/Spence have an excellent book about use cases which (unlike the UML specification) makes a lot of sense. There are also other well known authors teaching the same school (along Ivar Jacobson).
i have a basic idea about DHT and P2P. I need to explain how DHT is used in a P2P network with an example. Thank you
Well there are structured, and unstructured p2p overlays, basically this means, that structured networks have rules that dictate where objects stored are going to be located, and how the network topology will be organized, unstructured overlays don't.
DHTs are the most popular examples of structured, overlays what it basically does is dictate how queries should be routed (ie finding who has object x), and how they should be placed, using varying methods, ie chord has a ring topology and uses consistent hashing + finger table, kademlia uses xor and a tree topology.
What is the meaning and use cases of Car Wakeup which is described in the specification of the communication system.
(AUTOSAR_SWS_CANNetworkManagement and ...)
There parameter descriptions, but there is no definition of the word.
I can only speculate about your background in automotive communication, so please forgive me for starting at the basics.
The point of network management is to switch off communication networks that are not needed at a certain point in time. Colloquially speaking, you put those networks to sleep.
The switch-off can very well extend to the entire vehicle, or the vast majority of communication buses on a vehicle.
Of course, at some point the communication busses are needed again, and for this purpose, you "wake them up".
If you create a new application which uses a distributed hash table (DHT), you need to bootstrap the p2p network. I had the idea that you could join an existing DHT (e.g. the Bittorrent DHT).
Is this feasable? Of course, we assume the same technology. Combining Chord with Kademlia is obviously not feasable.
If yes, would this be considered parasitic or symbiotic? Parasitic meaning that it conflicts with the original use somehow. Symbiotic, if it is good for both applications as they support each other.
In general: Kademlia and Chord are just abstract designs, while implementations provide varying functionality.
If its feature-set is too narrow you won't be able to map your application logic onto it. If it's overly broad for your needs it might be a pain to re-implement if no open source library is available.
For bittorrent: The bittorrent DHT provides 20byte key -> List[IP,Port] lookups as its primary feature, where the IP is determined by the sender IP and thus cannot be used to store arbitrary data. There are some secondary features like bloom filter statistics over those lists but they're probably even less useful for other applications.
It does not provide general key-value storage, at least not as part of the core specification. There is an extension proposal for that
Although implementations provide some basic forward-compatibility for unknown message types by treating them like node lookup requests instead of just ignoring them that is only of limited usefulness if your application supplies a small fraction of the nodes, since you're unlikely to encounter other nodes implementing that functionality during a lookup.
If yes, would this be considered parasitic or symbiotic?
That largely depends on whether you are a "good citizen" in the network.
Does your implementation follow the spec, including commonly used extensions?
Does your general use-case stay within an order of magnitude compared to other nodes when it comes to the traffic it causes?
Is the application lifecycle long enough to not lie outside the expected churn rates of the target DHT?
Is there a formal/traditional way to describe data/command exchange protocols? For example, for programming languages there are multiple approaches to describe the syntax and semantics (like: http://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form).
The approach I am looking for is rather utilitarian (in contrast to academic). I need something for day-to-day use for data exchange description while working on specifications, just to transfer/spread clearly the idea to others. So, if there is something that is not recognized as a de-facto standard but is useful - it is ok too.
I took a look at UML sequence diagrams and "Formal Methods for Communication Protocol Specification And Verification, by Carl A. Sunshine, 1979". Former method is missing the description of "payloads" (at least from what I understood) while latter one is rather an educative paper describing considerations rather than methods (I am still going through this paper, though).
Thanks in advance
Protocols are about messages sent in accordance to a series of interactions.
The best way to specify protocols that I have seen is with Colored Petri Nets (CPNs).
CPNs are based on ("uncolored") Petri Nets (PNs), which define how parallel activities synchronize, e.g., the message responses, by using Places to represent possible states, Tokens-in-places to represent state, and transition (synchronization) gates to indicate where parallel states must coincide to make progress. Petri Nets can model Finite State Machines (an FSA is a PN that always has a "single token", e.g., the "current state") and so are a generalization; in fact, they can "exponentially compress" certain FSAs into very small descriptions and can thus be quite succinct even for complex interaction sequences. But a conventional PN does not address the data being exchanged.
CPNs generalize PNs to add data types. The tokens now have "colors" (funny way to say "data type") and transitions can not only synchronize but can combine tokens to produce other tokens, e.g., compute new values.
A protocol modelled as CPN thus has message content as data types, and PNs states to indicate the syncronization. If you've never used a CPN, it is really worth your trouble to learn what they are, because they are such a pretty generalization of FSAs.
Regarding OPs' "utilitarian" remark, there are very good tools available at CPN Tools, including graphical modelling and code generation.
In telecommunications, the standard for describing interaction between network elements is Z.100 : Specification and Description Language (SDL) and the companion Z.120 : Message Sequence Chart (MSC) recommendations. The suite includes a testing framework.
A more mathematically bent approach would be to use various state machine models of some type.
One of the early publications, Design and Validation of Computer Protocols (1991), was written by Gerard Holzmann to describe the SPIN model checker and the PROMELA language.
Almost any other notation like TLA+, Petri-nets, Alloy, CSP, Z, ... can also be used to reason about protocols and the choice often depends on familiarity and tools availability.
If rigour is not essential, then Harel state charts provide a notation familiar to many engineers.
Fundamentally, the problem with sequence charts on their own is that they describe a single trace through the protocol. They cannot easily show the non-determinism required to describe parallel operations, and struggle to succinctly represent choice. When extended with hierarchical message charts (HMC) then they fall back into the state machine space.
If by "utilitarian" you mean "useful", consider Petri Nets. Please see my reply below or consider a PDF version of the reply.
first page of reply http://www.aespen.ca/AEnswers/lMtbX1428143440-0_Page_1.jpg
second page of reply http://www.aespen.ca/AEnswers/lMtbX1428143440-0_Page_2.jpg
For what it's worth, since you mention BNF: I believe I have read that Wirth used EBNF to specify protocols, with prose explaining which parts of the string were to be emitted by the client and which parts by the server. I am unable to find the reference off-hand, but my recollection is that the example I read was clearer than most protocol descriptions I have read elsewhere.