Suppose we have two phones (A) and (B). And i am sharing a file from one (A) to another phone (B). But we are not sharing anything from (B) to (A). In that case which model of Networking we are using.
P2P or Server-client Network
I think it is Server-client Network here. P2P is more difficult and not quite suitable for this problem.
I'll first roughly clarify the notions of Client-Server model and P2P model here:
Client-Server Model
Client-Server model is the networking model where the client initiates the communication to the server and the server responds accordingly.
Example
Your HTTP GET request to browse this Stackoverflow page is client-server model since your networking device first sends a GET request to the server and the server responds with the HTML page.
P2P Model
P2P model is the one where there is a node (or multiple nodes) that work as a mediator and help networking devices (in your case phones A and B) to communicate with each other.
Example
Skype uses P2P model to allow networking devices (e.g. smartphones that have Skype app installed) to communicate with each other. The networking devices first establish connections with intermediate nodes and then talk to each other via those nodes.
Therefore, I would say your case falls into the category of P2P because the two phones A and B most likely need some intermediate nodes in order to communicate with each other unless the firewall settings and other network-related configurations of the phones can be modified to allow direct communication (which is probably not the case here). Note that the communication between A and B doesn't have to be bidirectional to be characterized as P2P.
Related
So we have two architectural models in distributed systems, P2P and Client-Server
I'm already familiar with both concepts in general networking, but it has come to my understanding that in a Client-Server model, the server might as well be a client to another server, which really confuses me because wouldn't that basically be similar to P2P where every computer is considered a "peer"?
Why have the two models anyway?
It's not a very precise question, so excuse me if the answer isn't what you had in mind. Essentially, the Client/Server (C/S) and Peer-to-Peer (P2P) models express two different kinds of communication pattern: asymmetric and symmetric, respectively. In the C/S model, each participant is doing something quite different: one might be sending mail, and the other receiving it, or one is a web browser wanting content, and the other a server dishing it out. The P2P model involves participants cooperating among themselves to achieve the same task, such as file-sharing.
Perhaps what's confusing you about the C/S model is a pattern like a proxy, in which the proxy server is a server to some nodes, and a client to others. This is still very much the C/S rather than P2P model of operation, but the proxy operates in both the client and server roles, quite likely using the same protocol in both cases (it's generally called a "gateway" when the protocols are different). In the case of an HTTP proxy, for example, the browser client treats the HTTP proxy much like an ordinary web server. In fact, the proxy may be the web server as far as the browser is concerned: most decently large-scale websites are actually many servers behind load-balancing proxies, or similar. The proxy may not hold the data that is being requested, in which case it fetches it from some other web server in the role of a client.
P2P protocols, in contrast, tend to be doing the same thing at each node. Torrent-like file-sharing is an obvious example: participating nodes are distributing files between themselves. Some nodes have data which other nodes want. There may be nodes which are mostly receiving data (leechers) and nodes which are mostly sending data (seeders), but the protocol is the same for all participants.
Some applications will even benefit from a hybrid approach. In telecommunication applications, you generally want some nodes acting as servers in order to facilitate things like call establishment, but once a call is taking place, it's best if the end-nodes can communicate directly with each other as peers.
I am struggling to describe simply what the IP Application layer actually “is”. Some of my terminology may be “not quite right”, so I am happy to be corrected on my terminology as well. Is the application layer a “thing”? Or is it more “conceptual” than that? Is the Application layer on a particular node solely that collection of protocols (such as FTP, POP3, HTTP) that an application needs to adhere to if it is to successfully communicate with another remote application?
Conversely, if I write a program that does not strictly conform to an application protocol (say FTP) then there is nothing in the local “application layer” that will “stop” my attempt to communicate to the remote end using an invalid command? Whereas, if the remote end does conform to the application protocol, then it will reject or ignore my invalid communication attempt?
Or again, I could define my own protocol (not necessary as I guess all scenarios are already covered), and as long as my protocol was “robust and consistent” I could use it to communicate between two remote applications and everything would work? Or, is the Application layer a “thing” separate from the protocols?
The application layer is everything that's inside the application - that is, not within the IP stack (which covers network and transport layers).
If you want your application to communicate with an FTP server it needs to be able to speak FTP in order to work. If you write your own client-server protocol you can do whatever you want.
The network layers are there to make your life easier and to make applications compatible with each other. You can use or not use whatever you seem fit.
“An application needs to communicate with another application on a remote system. Any communication can be thought of as the exchange of messages and data between two partners. There are rules (protocols) that define for an application: what commands are available, the sequence that they can be exchanged between partners and any limitations on the data exchanged. For example: communication with an HTTP server uses commands: GET, POST and PUT (and others), whereas communication with an SMTP (mail) server uses: MAIL, RCPT and DATA, and similarly for other protocols. There are different protocols depending on the nature of the communication e.g. text message transfer, file transfer or video streaming. Any commands that are sent by either partner that do not obey those protocol rules is either: not delivered to, ignored or rejected by the remote application. Nothing prohibits application partners using their “own” communication protocol – for example Skype developed an uses its own protocol. However, there are standard protocols that handle most conceivable communication needs, so developing a new protocol may be unnecessary. If an application uses a “private” protocol its communication will be limited to remote applications that support the same private protocol. In addition to protocols, in a practical, real-world, system there are programming libraries (Programming interfaces) that enable the end-user application to request and participate in this communication. It is the end-user application’s responsibility to interact (send and receive data and parameters) with the (local programming) interface and the comms system’s responsibility to process those requests and deliver the data. In simplistic terms, one data transmission starts at one application and ends at another. However, IP provides other applications, such as DNS, that are used to set up connections, but the operation of these is not visible at the end-user application level. In summary, the collection of protocols and the programming interfaces available and used by an end-user application is the application layer on a system.”
The Gossip protocol used by many distributed systems e.g. Cassandra to communicate with other nodes in the ring. So, does it use HTTP or TCP protocol?
Also, what are the pros choosing one over another in distributed systems?
You can use any protocol you want (tcp, http, dns etc) to broadcast information regarding the state of your nodes from a cluster. In my opinion , you should focus on a gossip algorithm, and not really think about the "protocol" word from the naming. At it's core, it's all about broadcasting information between nodes. Each node sending it's own view of the cluster state to a subgroup of nodes, and the broadcast keeps going until all nodes share the same view. There are multiple ways of implmenting such a broadcasting algorithm so research more about it or try your own model :) .
Here is some nice info and pseudo code about gossip model/algorithms
HTTP and TCP are fundamentally different things as they work on different layers of the network stack:
https://en.wikipedia.org/wiki/OSI_model
If you look at the OSI Model TCP works on the transport layer (Layer 4) and HTTP works on the application layer (layer 7), The two perform different jobs. The transport layer is responsible for providing the functional mechanisms for transferring data. The application layer is built on top of the transport (and other) layers and provides items such as partner negotiation, availability and communication synching.
The two are not interchangeable with one another.
We're about to design an inhouse industry network consisting basically of the following: 1 server connected via wire to up to 100 proprietary RF access points (basically embedded devices), which each can be connected via radio to up to 100 endpoint embedded devices. Something like this:
Now, I'm wondering about some design decisions that we need to take and I'm sure there are plenty of similar designs out there and lots of folks with experiences of them, both good and bad. Maybe you can chime in?
All endpoint devices are independent and will communicate their own unique data to the server, and the other way around. The server therefore needs to be able to target each endpoint device individually. Each endpoint device pairs itself with 1 access point and then talks a proprietary RF protocol to it, TCP/IP is not an option there.
The server will know which endpoint device is paired with which access point, so when the server needs to talk to an individual endpoint device, the communication must go through the paired access point. Hence, the server needs to directly address the access point.
Question: Considering the limited resources available in the proprietary access point, is TCP/IP between server and access point recommended for this scenario? Or would you suggest something entirely different?
I find the diagram confusing:
If this isn't its own network and the server to AP link is running on your internal company network, there isn't really an option, there must be a TCP/IP stack on the AP.
If this is its own isolated network then what is the router for?
If this is, in fact, its own isolated network then you are right, there really isn't a need for the Ethernet connectivity at all. The overhead you will see on the wireless is huge, your no overhead ideal data rate is 250kbit/sec, running ZigBee on 802.15.4 # 2.4ghz point to point your real data throughout is usually around 20kbit/sec. A custom protocol should be able to obtain lower overhead but this would need to be defined.
If I were designing this I would choose a SoC for the AP that had on board 802.15.4 and CAN (Controller Area Network). Depending on size and data rate just get a PCI CAN card for the server and connect it up, use something like DeviceNet as your protocol layer for server to AP communications. This can be expanded by using CAN switches and repeaters. CAN is used all the time in industrial automation, a little googling can find you example of tens of thousands of nodes used in some manufacturing plants.
There are small TCP/IP stacks, for example LwIP.
You didn't mention the amount of data to be communicated, or bandwidth considerations?
A 3rd party TCPIP stack targeted at the 8051 would simplify all the networking issues with connecting 100 units. You probably will still end up with a proprietary protocol that sits on top of the tcpip stack but then it is just simple point-to-point communication between the server and each end point.
I want to develop simple Serverless LAN Chat program just for fun. How can I do this ? What type Architecture should I use?
Last year I have worked on TCP,UDP Client/ Server application Project.It was simple (Server listens to certain port/socket and Client connect to server's port etc..) But I have no idea about how to develop "Serverless" LAN Chat program. How can I do this? UDP,TCP,Multicast,Broadcast? or Should program behave like both server and client?
The simplest way would be to use UDP and simply broadcast your messages all over the network.
A little bit more advanced version would be to only use the broadcast to discover other nodes in the network.
Every node maintains a list of known peers.
Messages are sent with TCP to all known peers.
When a node starts up, it sends out an UDP broadcast to discover other nodes.
When a node receives a discovery broadcast, it sends "itself" to the source of the broadcast, in order to make it self known. The receiving node adds the broadcaster to it's own list of known peers.
When a node drops out of the network, it sends another broadcast in order to inform the remaining nodes that they should remove the dropped client from their list.
You would also have to consider handling the dropping out of nodes without them informing the rest of the network.
The spread toolkit may be a bit overkill for what you want, but an interesting starting point.
From the blurb:
Spread is an open source toolkit that provides a high performance messaging service that is resilient to faults across local and wide area networks. Spread functions as a unified message bus for distributed applications, and provides highly tuned application-level multicast, group communication, and point to point support. Spread services range from reliable messaging to fully ordered messages with delivery guarantees.
Spread can be used in many distributed applications that require high reliability, high performance, and robust communication among various subsets of members. The toolkit is designed to encapsulate the challenging aspects of asynchronous networks and enable the construction of reliable and scalable distributed applications.
Spread consists of a library that user applications are linked with, a binary daemon which runs on each computer that is part of the processor group, and various utility and demonstration programs.
Some of the services and benefits provided by Spread:
Reliable and scalable messaging and group communication.
A very powerful but simple API simplifies the construction of distributed architectures.
Easy to use, deploy and maintain.
Highly scalable from one local area network to complex wide area networks.
Supports thousands of groups with different sets of members.
Enables message reliability in the presence of machine failures, process crashes and recoveries, and network partitions and merges.
Provides a range of reliability, ordering and stability guarantees for messages.
Emphasis on robustness and high performance.
Completely distributed algorithms with no central point of failure.
Apples iChat is an example of the very product you are envisioning. It uses Bonjour (apple's zero-conf networking protocol) to identify peers on a LAN. You can then chat or audio/video chat with them.
I'm not entirely sure how Bonjour works inside, but I know it uses multicast. Clients "register" services on the LAN, and the Bonjour protocol allows for each host to pull up a directory of hosts for a given service (all without central management).