-6

In Tanenbaum's Computer Networks book

Three concepts are central to the OSI model:

  1. Services.
  2. Interfaces.
  3. Protocols.

Probably the biggest contribution of the OSI model is that it makes the distinction between these three concepts explicit.

Each layer performs some services for the layer above it. The service definition tells what the layer does, not how entities above it access it or how the layer works. It defines the layer’s semantics.

A layer’s interface tells the processes above it how to access it. It specifies what the parameters are and what results to expect. It, too, says nothing about how the layer works inside.

Finally, the peer protocols used in a layer are the layer’s own business. It can use any protocols it wants to, as long as it gets the job done (i.e., provides the offered services). It can also change them at will without affecting software in higher layers.

These ideas fit very nicely with modern ideas about object-oriented programming. An object, like a layer, has a set of methods (operations) that processes outside the object can invoke. The semantics of these methods define the set of services that the object offers. The methods’ parameters and results form the object’s interface. The code internal to the object is its protocol and is not visible or of any concern outside the object.

Although the protocols associated with the OSI model are not used any more, the model itself is actually quite general and still valid, and the features discussed at each layer are still very important.

I am trying to understand the three concepts (services, interfaces and protocals).

What services and interfaces does (the layer of) the HTTP protocol provide?

  • Are the HTTP methods (e.g. GET, POST) services or interfaces?
  • Are the formats of HTTP requests and responses not part of services or interfaces?

Go down one layer:

  • Is socket API interface of the transport layer?

  • Are TCP and UDP two protocols that implement the transport layer?

Thanks.

Improve this question
10
  • 14
    As with many of your questions, the answer is simply that terms mean precisely what they are defined to mean within the context they are defined in. The terms you are talking about have a specific meaning within the OSI protocol stack. The protocols you are asking about are Internet protocols, not OSI protocols, so terms that are defined for OSI protocols simply don't apply to them. Commented Nov 18, 2020 at 8:00
  • 9
    To support @JörgWMittag's comment, and to point out a recurring issue with many of your posted questions; you keep trying to theoretically learn something but do not put sufficient care in making sure that you know (or are using) the contextually appropriate definitions of the words related to your question. If you don't invest your due diligence in understanding the words themselves (in the specific context you're using them), then any communication or documentation on the subject will never be understandable, no matter how often you re-read it. Commented Nov 18, 2020 at 11:02
  • 10
    To address the comments in your question: 1) Ben's comment is neither ignorant, arrogant, abusive, nor abusive. It's a stock comment (that presumably came with a close vote) that reflects that he thinks the question would be better suited for another site. Whether he's correct or not doesn't make it what you say it is. 2) The comments from Jorg and Flater, believe it or not, are actually trying to help you. They're suggesting that some practical application would help to go along with all of the theoretical things your reading and help you understand better... Commented Nov 18, 2020 at 13:26
  • 10
    @Tim The sites on this network have certain rules about what types of questions are appropriate, as well as what kind of language. You seem to think that unlimited free speech applies here which isn't the case, no matter how much you want it to be otherwise. Once you understand that and learn to accept constructive criticism on your questions, I think you'll have a much better experience, your questions will be better received, and you'll be less likely to get hit with a ban. Commented Nov 18, 2020 at 13:56
  • 10
    @Tim I'm not threatening you in any way. I'm attempting to tell you something about human nature and how people react to others in order to give you tools to encourage others to help you. If someone votes to close your question or gives suggestions on how to improve, instead of getting defensive and calling comments abusive or otherwise, consider taking their suggestions into account and updating your question accordingly. Commented Nov 18, 2020 at 18:35

1 Answer 1

Reset to default
2

Are the HTTP methods (e.g. GET, POST) services or interfaces?

Neither. Possibly both.

Each layer performs some services for the layer above it. The service definition tells what the layer does, not how entities above it access it or how the layer works. It defines the layer’s semantics.

The HTTP layer's services are provided to an application using an HTTP library.

So, if by "GET" you mean "asking my HTTP library to send a GET request", then you're going to call the library interface requesting that service.

But if by "HTTP GET" you mean "send a GET request to an HTTP peer", then you're not dealing with that peer via the OSI model at all - your local HTTP library is encapsulating that for you (or you are implementing one yourself). The ambiguity arises from the fact that the "HTTP GET" method is a protocol detail, which might also be exposed directly through the interface.

Are the formats of HTTP requests and responses not part of services or interfaces?

No, they're protocols. You can tell because the "P" in "HTTP" stands for protocol.

Is socket API interface of the transport layer?

Sort of. See for example wikipedia.

The normal sockets API covers whichever OSI-transport-layer protocols are baked into your kernel, but:

  • there may be other OSI-transport-layer protocols provided by libraries (so the sockets API is not the only interface to this notional OSI layer)
  • the sockets API also provides some features associated with the session layer, according to that link (ie, named AF_UNIX pipes).

These are all related to the fact that no-one really uses the OSI model itself any more. It's been superseded. The book you quoted was simply suggesting that

  • self-contained entities (whether objects or layers)
  • with defined interfaces
  • and with defined semantics
  • which hide implementation details (like protocols) inside

are a good idea. Not that anyone continue using the OSI model itself. So asking whether the socks API belongs to a particular layer - or whether an HTTP protocol detail has a particular classification - is missing the point completely.

Improve this answer
1
  • What I remember from my CS classes is that the OSI layers were an attempt to establish a systematically sound theoretical model and foundation for a networking implementation. Then TCP/IP came around which simply did things; it took shortcuts through the layers where it was practical, was open source (in the sense that people could read it, as part of BSD) and was very successful. Turned out that being too anal about the layers keeps you from doing things efficiently. But the OSI model is still used as a mental model, in order to systematically think about implementations. Commented Feb 20, 2024 at 7:46

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.