I have worked (tested) on different types of API/Channels including SOAP, REST, TCP/IP and ISO 8583 Messages.
In terms of OSI Network Layer Model, do they communicate on different layers and if yes then which type of APIs/Channels communicate on which layer?
If they communicate on different OSI Layers, then why or what difference does it make? Is it in some aspect of encryption/security or something else?
Any guidance will be helpful. Thank You.
Related
Im having a hard time Categorizing the USB Protocol in the layers of the OSI Model model.
Im guess there are 7 layers to begin with. These are the Informations i believe that corresponds to the layers:
7. Application (Software)
- Application specific
- Additional Drivers / Protocols
6. Presentation (Software)
- Application specific
- OS
5. Session (Software)
- Power mode regulation
- Configuration
4. Transport (Hardware)
- Split data into Frames
3. Network (Hardware)
- Client Adress 1 - 127
- Endpoints
2. Link (Hardware)
- CRC 5 Checksum for tokens
- CRC 16 Checksum for data packets
1. Physical (Hardware)
- Differential voltages (D-, D+)
- NRZI
- USB Plug
Is this correct so far?
How do hubs work? i believe they can "select" between clients just like an ethernet switch. doesn't that mean there the Master hast to send 2 addresses in every packet. One for the next immediate communication partner like Mac address and one for the Destination address like IP address ?
Maybe there are Usb Masters amongst us, who can send OUT Packages to this post, to help me out ;) I would be Very happy to send an ACK response :)
haha okay enough puns
When I taught these subjects, my students agreed with me that as they learned, and used, more precise words, it was easier for them to find answers to their questions. I could be wrong, but I think viewing USB through the OSI 7-layer model will be a little easier if you change "USB Protocol" to the more precise, USB specification.
The USB specifications include multiple protocols spread across multiple layers. The Physical layer includes specifications for things such as connectors, cables, power, and shielding.
The logical functions of USB protocols do not map perfectly onto the OSI model. Some protocols span two or three layers of the OSI model. But, it's possible to see which parts of which protocols fit in which layers. If the protocol is only concerned about signals between two nodes that are physically connected directly to each other, then it is the Data Link layer.
The Network layer is only about managing the bus when there are at least three nodes on the bus, such as identifying the nodes (addressing) and deciding where to send a packet (routing).
The Transport layer usually asks and answers the question, "Can you hear me now?" Or, you can think of it as analogous to using a ton of tracking numbers on the DHL website to track an order that has tons of packages. It is important between two nodes that are not directly physically connected to each other. The Data Link layer asks similar questions, but those questions are typically focused on individual signals (i.e., packets). The Transport layer does more sophisticated things such as putting packets in a specific order, dividing and combining packets, and tracking which packets in a set of packets were sent or received.
In USB, determining which node can use which part of the bus at what time is very important. Those protocols (mostly?) correspond to the Session layer.
I don't think any aspect of any USB specification corresponds with the Presentation or Application layers.
The USB-IF specification for USB4 includes their conceptual model for the USB functional stack. See section 2.2.1.
Good luck!
Hubs work on the First Layer. They just connect all the ports' pins together.
Can someone explain to me what is CAN BUS protocol stack? Is it CAN BUS+ higher layers, like CANopen with 7 layers or something else, and can someone explain how can I use CAN stack, how I connect it with CAN bus, and why I need it?
Thank you
Yes it is CAN hardware with higher layer protocols, such as CANopen, J1939 or DeviceNet.
In terms of the "OSI model", it only really makes sense to speak of layers 1-3 and 7, where CAN is layers 1 and 2 and a protocol like CANopen roughly provides layers 3 and 7. Roughly, since CAN-open also comes with hardware specifications such as baudrate, sync point & stub length recommendations.
What's known as a "protocol stack" is really just a library with a platform-independent API, usually delivered with hardware-specific drivers. If the vendor claims that they support a particular MCU, then it usually means that you get the drivers from the vendor.
So basically you buy this pre-made library and integrate your program with it, then get standardized protocol behavior on the CAN bus, necessary to communicate with other nodes implementing the same protocol. Writing such a library yourself is no small task, particularly not for CANopen which is a big standard, where you are probably just going to use some 10% of the available functionality.
I am very new to SDN and want to know just a basic understanding of it so that I can explain to some simple what it is. From what I know that the architecture is broken into the three layers. The infrastructure layer is just the switches and routers, and other devices that makes up a network. The controller layer maps how the devices are connected and how forwarding of packets should be sent from one device to another. For the controller layer to actually do the work in mapping and knowing how to forward the packets, the application layer provides the logic to do so and this is the layer where you create your network application in certain programming language like Python. Did I get a basic understanding of how SDN layers work?
We need to understand few terms before going to SDN.
Control Plane: The plane that determines where to send traffic
Data Plane: The plane that executes these decisions and forwards traffic
Management Plane: Element of a system that configures, monitors, and provides management, monitoring and configuration services to, all layers of the network stack and other parts of the system
Traditional Network Devices:
Control Plane, Management Plane and Data Plane reside on device itself.
Each device has its own brain and disconnected from each other and uses all sorts of protocols to stay connected.
Yet such protocols are complex and levels of resiliency to control action of such protocols also complex.
Think of traditional network as the type of network that is more prone to failure due to multiple disconnected brains not working together with one another.
SDN: (Decoupling hardware from Software)
SDN architecture is divided into 3 layers
Application Layer
Control Layer
Infrastructure Layer
Infrastructure Layer:
Consist of Network Devices which contains Data Plane and work on Open Flow Protocol or you can say uses Open Flow API to communicate.
Control Layer:
Consist of Control Plane and Management Plane.
Application Layer:
In this layer user can get an overview of Devices and see Topology.
Link between Application and Control Layer is generally called NorthBound Interface
Link between Control Layer and Infrastructure is called SouthBound Interface
Benefit of SDN:
Decoupling Control and Data planes involves leaving the data plane with network hardware and moving the control plane into a software layer.
By abstracting the network from the hardware, policies no longer have to be executed on the hardware itself.
Instead, the use of a centralized software application functioning as the control plane makes network virtualization possible.
You may find useful this: SDN Layer Architecture
I am looking at putting together a communications protocol for an embedded application, but I don't know much about high-level communications such as TCP/IP, etc. I'm more used to dealing with bits and bytes on I²C and SPI, etc.
Someone has suggested that I use a VISA (virtual instrument software architecture) I/O API with SCPI (standard commands for programmable instruments) command syntax. What layer would these sit at on the OSI model? I'm thinking VISA would be application and SCPI presentation?
Someone else has suggested using SSH, again as I'm not sure what layer VISA/SCPI sits at, I don't know how SSH would affect the design.
Since you're basically just using the network to pass data between a hardware API and an application, you're on layer 7(application) of the OSI stack.
I had a discussion with my manager, he said tcp is faster than http because of tcp is work on layer lower than http.
Then I remember about the OSI Model that I learnt in university, so I think what he meant is because http work on application layer but tcp work on transport layer (which is 2 layers belows) so is faster...
So my questions is:
Is lower layers works faster than upper layers is becasue there is less layers need to access when doing data transfers betweens two computers?
If so, that's mean when we use tcp (i.e with WCF), the commnicuation will be start at transport layers => down to physical layer => another computer's physical layer => up to transport layers? But I throught the data still need to be understand by the application, so it will still has to goes up to Application layer?
Thanks in advance.
There is always a layer above TCP. The question is really about how much overhead the stuff above TCP adds. HTTP is relatively chunky because each transmission requires a bunch of header cruft in both the request and the response. It also tends to be used in a stateless mode, whereby each request/response uses a separate TCP session. Keep-alives can ameliorate the session-per-request, but not the headers.
I noted the WCF tag, so I guess you're comparing NetTcp to for example BasicHttp. As #Marcelo Cantos pointed out, both drive on the TCP protocol.
Whereas the BasicHttpbinding uses HTTP for transport, a message is first encapsulated in XML (which is pretty verbose and data-eager) and then sent through HTTP, using lots of data for headers.
On the contrary, NetTcp uses a (proprietary?) protocol, where the message encoding and headers are specifically designed to decrease bandwidth usage.
In a common scenario you won't see any difference, but when dealing with lots of requests or larger amounts of data (especially binary data, which has to be encoded to fit in XML which increases its size), you might gain benefits by using NetTcp.
You are correct: TCP and HTTP are protocols that operate on different layers.
In general: in order for applications to utilize networking they need to operate at the application layer. The speed that any given protocol goes depends on the overhead it demands. HTTP typically operates over TCP, so it requires all of the overhead of TCP, all of the overhead of the layers under TCP, and all the overhead that HTTP requires itself (it has some rather large headers).
You're essentially comparing apples to oranges in comparing the speeds of TCP and HTTP. It makes more sense to compare TCP vs UDP vs other transport layer protocols -- and HTTP vs FTP vs other application layer protocols.