Re: Example of OSI package/data structure?

[Patrick Hohmeyer <pi3_1415926536@yahoo.ca>]

Hmm, no help, just some hints ;-)

Vincent Smeets wrote :

> Hallo,
> 
> Can someone point me to an example of an implementation for the ISO/OSI
> protocol stack?
> 
> I have a description of a protocol that has to be coded in Ada95. I it
> now coded (hacked) in a bad form in Ada83 and I want to redesign it for
> Ada95.
> 
> First I need a package structure. I want to decopple every layer as much
> as possible and was thinking of a tagged type for the device and extend
> it in every next layer. I have three ideas from which I think the first
> is the best (your opinion please?):
> 
> OSI
> OSI.Physical
> OSI.Physical.Data_Link
> OSI.Physical.Data_Link.Network
> OSI.Physical.Data_Link.Network.Transport
> OSI.Physical.Data_Link.Network.Transport.Session
> OSI.Physical.Data_Link.Network.Transport.Session.Presentation
> OSI.Physical.Data_Link.Network.Transport.Session.Presentation.Application

Why do you want Data_Link inherit from Physical ?
This would give Data_Link the same interface as Physical
plus an addition.
Is that what you want ?
Shouldn't Data_Link and Physical be two complete different interfaces.

And it would label Data_Link an extention of Physical.
But aren't in the OSI philosophy these two *independent* layers,
communication with each other through an interface?

I simply dont see my Browser as an extended Ethernet card.
IMHO he _uses_ the Ethernet card, but he _is_ _not_ an Ethernet card.

But if you want to go with your "extention" vision,
tagged types and the first package structure are appropriated.

I recommend the "use" vision.
There the third structure and no tagged types are recommended.

The "extention" vision makes it very hard to have 2 Data_Link go over
the same physical device, as they are an extention of a Device,
so 2 different Data_Links _are_ 2 (different) physical devices
and I dont see how you are gonna solve this paradox.

That's why I'd prefer the "use" approch.

> OSI
> OSI.Application
> OSI.Application.Presentation
> OSI.Application.Presentation.Session
> OSI.Application.Presentation.Session.Transport
> OSI.Application.Presentation.Session.Transport.Network
> OSI.Application.Presentation.Session.Transport.Network.Data_Link
> OSI.Application.Presentation.Session.Transport.Network.Data_Link.Physical

Physical isn't an extention of Data_Link so this one definitly not ;)

> OSI
> OSI.Physical
> OSI.Data_Link
> OSI.Network
> OSI.Transport
> OSI.Session
> OSI.Presentation
> OSI.Application

I would go with this one, but it depends on how you see the layers.
As extentions of each other or as independent entitys who communicate?

> Next; what type definition can I use for my device. As I only have two
> physical devices, I would like to define only two variables in the
> package Physical that has to be used for the operations and not allow
> the user to define extra variables. Something like:
> type Device (<>) is tagged limited private;
> Device_1 : Device;
> Device_2 : Device;
> The problem is that this doesn't work and if the type is extended, the
> variables has to be redefined to contain the extension.

First question :
  Why do you want to limite you to 2 vars in the ads?
  Might it be possible that you will reuse the package on
  a system with more than 2 devices?

Second :
  When the user cant define variables, how is he supposed to
  work with the type?
  What you really want is not preventing the /definition/ of variables,
  but the /initialization/ of variables.

Limited private is a good choice for the type.
Then you need an initialization procedure
(a function or constant wont work, as the user cant assign anything)
something like :
procedure Init_Device (Device_To_Init : out Device;
  Device_Number : in Natural);
and when Device_Number is greater than the number of devices
in this implementation, you raise an exception.

This one lets the user point two variable Device
to the same physical device.
To prevent this, you may mark a Device "occupied" until
it is liberated with a second function.
Think like a file.
You may even use an only slighly modified Sequentiel_IO.ads for
the specification of the Physical package.

> I hope you have enough information. Can you give me some help or point
> me to an example?
> 
> Thanks,
> Vincent
> 

-- 
Patrick Hohmeyer