What is the deal with OSI model? Is it still relevant?

What is the deal with OSI model? Is it still relevant?

Attached: osimodel.png (500x551, 120K)

Other urls found in this thread:

youtube.com/watch?v=s9YRGBFq6BM
twitter.com/SFWRedditVideos

Never was, TCP/IP is the only real model. Don't waste time on academic bullshit.

(Same is true for programming lnaguages btw, e.g. Haskell)

/close

>TCP/IP is the only real model
OSI contains TCP/IP m8

And a whole bunch of other nonsense. It's bloat.

I use it as we speak

most people that shit on osi do so out of ignorance. it's not a recipe or a standard, it's an abstract reference model.

you don't have to use all the layers, the layers don't have to be in that order, you can add other layers, but generally it helps when setting stuff up and/or communicating with other people about the subject.

those same people would probably say that patterns are also stupid.

(you)

>you don't have to use all the layers, the layers don't have to be in that order, you can add other layers, but generally it helps when setting stuff up and/or communicating with other people about the subject.
Why the hell did my teacher make me memorize this shit then ffs

Then why are all mainstream programming languages copying features from Haskell, 20 years later?

>Why the hell did my teacher make me memorize this shit then ffs

> it helps when setting stuff up and/or communicating with other people about the subject.

although 90% of people who learn it will never use it probably.

For the same reason mainstream programming languages have been copying features from Lisp for over half a century.

Layer 8 is where the problems sit.

The OSI model is a poor copy of the IBM SNA, which preceeded it.
It is just enough different to avoid legal action and to allow the OSI to quibble about the differences.

Hugely relevant. Let's send an email, shall we?

7: You use Thunderbird to craft and send an email
6. You use the MIME format to structure the to/from/subject/body/base64 attachments
5. You submit the message via SMTP and authenticate with TLS
4. The process of SMTP goes over TCP or UDP, depending on the circumstance, but is generally TCP for SMTP.
3. The outbound email hops/bounces between mail servers which have logical public IP addresses.
2. Hops between intermediary devices have data-link layers addresses, typically MAC addresses but could theoretically be other stuff like carrier pidgeons with identification tags.
1. Bits are transmitted on a media, maybe copper, fiber, or on the paper that was wrapped around the pidgeon's leg.

TCP/IP is fine but it's not the whole story to any given circumstance.

This. Shitty bait thread.

Yet there are people that agree with OP. I don’t know why I still come here

It never was. There was always 4 layers in practice and with things like mosh, quic and likely more datagram based protocols to come, you can all but disregard the concept of the kernel layer providing reliable transportation altogether.

Gookmoot should rename this board from Technology to Consumer Electronics desu.

TCP/IP is the whole story. Just because you want to take an example of a poorly designed protocol and throw your misguided concepts on it doesn't make the osi 7 layer model utter rubbish.

I've got a BSc in CS and this is the first real world example of OSI I've seen.
Good post, user

what's the point of a fucking degree if every nigger can get it.

Completely explain DNS using only the TCP/IP model.

Layer 7: Conversation about the weather
Layer 6: Only one person "talks" at a time, they speak at a "pace" that both persons agree to. They also agree on a language/dialect to use.
Layer 5: The session begins with "hello" and ends with "okay I'll talk to you later"
Layer 4: Dynamic process where if a piece of conversation is missed, either person can ask for clarification
Layer 3: Both people know who they are conversing with
Layer 2: There might be a middle-man or courier between the two conversationalists.
Layer 1: The conversation is completed via text on paper, it can be signed with ASL or can be spoken aloud. This might be changed in-between "bounces" if there happens to be a middle man.

You can do this shit all day.

Its good for academics and getting certs. The DoD model is what the real world uses

Send https over tcp or soon to be udp via http3, over through some kernel gating bullshit that throws data at an asic that hits some dns over http bullshit. Easy. What happens in userspace is irrelevant to the shitty model which is utterly moronic way of making a networked application.

Stick to fixing cars, user

youtube.com/watch?v=s9YRGBFq6BM

uh

maybe not

Are you mad that dns over http is superior to dnssec? Utter morons like you unironically think you can break application protocols over replaceable layers? Jesus fuck.

Who said I'm mad? The two models get you to the same results. My preference to OSI is heavily influenced by the fact that it's a more precise way to describe reality and makes room for things like encryption and security implications.

The example given of DNS over HTTP is perfectly fine, but it leaves out the question of who started the session, which is an incredibly important topic. You're basically obfuscating a lot of non-trivial steps in the resolution process.

Obviously you can't break down every application or protocol to replaceable layers but it sure makes things easier. That's why we can DNS over HTTP in the first place, is because DNS queries and responses have a well-defined structure (layer 6) to use, and the layer 7 client resolvers and public recursive servers can be upgraded to support that.

unsure why you're buttflustered, and about what exactly?

It doesn't leave anything out. The shitty tcp state machine and the kernel is responsible for the session of the connection and the reliable transportation. The application Interworkings are all coupled and are not worth enumerating. The 4 layer model is simply a more correct way of viewing network applications. It's that simple.

>It doesn't leave anything out
This is true. I could also use a one-layer model of "input in, process, output out" and I don't leave anything out. What we're disagreeing on is how many layers is appropriate before the distinctions become too fine to tell apart.

>The shitty tcp state machine and the kernel is responsible for the session of the connection and the reliable transportation
I'm okay with this, but the NIC card is actually responsible for frame handling.

>The application Interworkings are all coupled and are not worth enumerating
I fully disagree with you. Application versions change and the session method or port number might change. How many other nodes a single process is connected to is unpredictable and is therefore worth modeling a session method. The presentation layer can also have changes in structure of code or be extended without the application's knowledge, for example, a web browser can just deal with streams of raw data and ask the user "I don't recognize this data, but I got it from this session with this node, what do you want done with it? dump to disk? open with another file?"
Also you could split input from a single session/presentation layer to multiple programs if you *really* wanted to as a method of saving bandwidth , I don't know what your use case might be but splitting the application layer into three assists with these potential realities.

>The 4 layer model is simply a more correct way of viewing network applications
[Citation needed]

>the tcp state machine mk 2 is capable of instantly teleporting signals to any other compatible tcp state machine mk 2 at the press of a button. no matter the distance, no matter the topology, it just happens and the methodology is not worth enumerating.

frankly I'm a little saddened that you take routing, discovery, mapping and flow control so for granted. you're basically saying I should kms.

>Layer 4: Dynamic process where if a piece of conversation is missed, either person can ask for clarification

I think that should be done in layer 2

That's a good clarification, actually. That's the problem with models, you can only be so accurate.

A better way to word that might be that the people communicating at the very least know when something was lost in transit, and it's up to them to ask for clarification if necessary or infer what the other person was saying through context.

Checksums are used in both UDP and TCP.

DNSSEC has nothing to do with DoH, you're a literal and unironic brainlet

OSI is a rather very shitty model because it fails to uniquely classify a lot of real things but it got popular so it's now easier to teach or communicate with with other people. There isn't really any alternative in this regard.

>OSI model is irrelevant
state of Jow Forums

the bottom 4, maybe the top if you consider it as such, exist.
the other bits are memes.

at the bottom, you got the physical connection, the system that moves signals back and forth.
next up, you have the bit that moves messages back and forth, not merely a signal.
the next layer is the part that directs things to different places, develops the concept of location or address.
then, you've basically got the protocols of the software. these just unify various tools programs/OSs use. glorified drivers.
and if you consider it a layer, the program itself using them.

Best thread on Jow Forums right now thanks

Please
Do
Not
Throw
Sausage
Pizza
Away

What the fuck do you mean by the other bits are memes? There is code for all of it and they all exist as their own standards. TLS/SSL and HTML being great examples of the session and presentation layers, respectively.

Can you expand on this? I'm interested in a more detailed model.

It over complicates everything.

I had to learn the OSI model like 4 times in my education and literally the only time I had to use it was during tests.

Attached: 1550867295519.png (500x551, 124K)

Not everyone is a code monkey javascript baby like you. There's these things called network engineers who actually care about the other layers. Crazy, huh?

Here is the thing. Layer 4-6 are only optional and abstract design, so that you can actually reuse existing solutions without having to adapt your software for every single use case.

>OSI contains TCP/IP m8

TCP and IP can be classified roughly as L4 and L3 in the OSI model, but the IETF model is not an incarnation of the OSI model. The key think to realize is that IP is really a meta-network grafted on top of heterogeneous hardware-specific networks. Mapping itself to concrete lower layers with ad-hoc translation shims like ARP was not at all what OSI intended.

Consider the OSI Network layer, which is supposed to handle pathing/routing. Is Ethernet considered this when switching traffic instead of broadcasting via hubs? What about TCP, which people call L4 but also includes functionality from L5 like graceful connection closing?