This is going to seem like a basic OO question, but it comes up and bites me
every now and again.

Suppose we have a multi-tiered protocol to implement, what is the logical,
OO way to design the handler? For example, let's say that we have to
implement the ISO 7-layer protocol, or something like an Allen-Bradley
master-slave protocol. At the lowest layer we might only need to top and
tail the data being transported, such as DLE STX [data from network layer]
DLE ETX BCC.

[data from network layer] might comprise DST SRC CMD STS TNS [data from
application layer]

[data from application layer] might comprise FNC ADDR [data].

We could have a class for each layer, where each contains an instance of the
next layer down, e.g.

Public Class ApplicationLayer

Private m_NetworkLayer As NetworkLayer

End Class

Public Class NetworkLayer

Private m_LinkLayer As LinkLayer

End Class

Public Class LinkLayer

Private m_TransportLayer As TransportLayer

End Class

In the last case, TransportLayer could be a serial link implementation, or
some other type of communications handler.

Each layer would pass data on to the next layer down, and return results to
the caller; the next layer up.

Is this how other people would do it? I can't put my finger on why, but
there is something that just doesn't sit well with me about this method.
What if we want to dispense with the network layer? Do we have to change the
code in ApplicationLayer to keep a local LinkLayer instance? Wouldn't that
upset things a bit?

I suppose each local instance should be based on a common interface, so that
layers become, to some extent, interchangeable. Have I just answered my own
question?

What if we want to change the comms layer to something else: does that work
in the same way?

Also, the comms layer will probably need some kind of dynamic configuration,
such as baud rate, stop bits, etc. How do we configure this layer? The only
thing that has a handle to a TransportLayer object is the LinkLayer object,
but the LinkLayer knows nothing of baud rates and stop bits. Where does the
information come from? Do we have to pass it down the layers until the
object that understands the configuration gets it? That doesn't seem right
at all.

The same problem could occur in the network layer. An address is probably
required to ensure that the correct target gets the data, but where is this
address managed?

A lot of this is me just thinking out loud, but I would be interested in
other people's views. For example, is there a design pattern for this?

TIA

Charles

Charles Law wrote:
> This is going to seem like a basic OO question, but it comes up and bites me
> every now and again.
>
> Suppose we have a multi-tiered protocol to implement, what is the logical,
> OO way to design the handler? For example, let's say that we have to
> implement the ISO 7-layer protocol, or something like an Allen-Bradley
> master-slave protocol. At the lowest layer we might only need to top and
> tail the data being transported, such as DLE STX [data from network layer]
> DLE ETX BCC.
>
> [data from network layer] might comprise DST SRC CMD STS TNS [data from
> application layer]
>
> [data from application layer] might comprise FNC ADDR [data].
>
> We could have a class for each layer, where each contains an instance of the
> next layer down, e.g.
>
> Public Class ApplicationLayer
>
> Private m_NetworkLayer As NetworkLayer
>
> End Class
>
> Public Class NetworkLayer
>
> Private m_LinkLayer As LinkLayer
>
> End Class
>
> Public Class LinkLayer
>
> Private m_TransportLayer As TransportLayer
>
> End Class
>
> In the last case, TransportLayer could be a serial link implementation, or
> some other type of communications handler.
>
> Each layer would pass data on to the next layer down, and return results to
> the caller; the next layer up.
>
> Is this how other people would do it? I can't put my finger on why, but
> there is something that just doesn't sit well with me about this method.
> What if we want to dispense with the network layer? Do we have to change the
> code in ApplicationLayer to keep a local LinkLayer instance? Wouldn't that
> upset things a bit?

This feels wrong to me because I don't see how containment correctly
describes the relationship of layers to each other - they feel like
siblings more than parents/children.


>
> I suppose each local instance should be based on a common interface, so that
> layers become, to some extent, interchangeable. Have I just answered my own
> question?

How about this: A given scenario of layers is a Stack (I believe this
term is the one used in networking). A Stack contains an *ordered* set
of Layer objects. The base Layer class defines Transmit and Receive
methods that operate on a <unit of transmission> - each specialization
of Layer overrides as necessary.

There are two levels of inheritance from Layer - for example for
networking the first ('generic') level would be the 7 ISO levels,
ApplicationLayer, TransportLayer, etc; then deriving from *those* would
be *particular* ('specific') layers, eg TCP would derive from
TransportLayer (assuming I've correctly remembered which ISO layer TCP
maps to...)


>
> What if we want to change the comms layer to something else: does that work
> in the same way?
>
> Also, the comms layer will probably need some kind of dynamic configuration,
> such as baud rate, stop bits, etc. How do we configure this layer? The only
> thing that has a handle to a TransportLayer object is the LinkLayer object,
> but the LinkLayer knows nothing of baud rates and stop bits. Where does the
> information come from? Do we have to pass it down the layers until the
> object that understands the configuration gets it? That doesn't seem right
> at all.

With the Stack model each generic and specific Layer is free to
implement properties as required, so ApplicationLayer would implement
Property FriendlyName, then DOOMLayer (Inherits ApplicationLayer) would
always return "DOOM" for this property, and so on.

>
> The same problem could occur in the network layer. An address is probably
> required to ensure that the correct target gets the data, but where is this
> address managed?
>
> A lot of this is me just thinking out loud, but I would be interested in
> other p

What I haven't thought about at all is the <unit of transmission> - how
about a Byte(), then you could have these methods on Layer (which is
MustInherit):

Public Function DecorateForTransmission(ToSend() As Byte) As Byte()
Public Function UndecorateOnReception(Received() As Byte) As Byte()

(shorter names in real thing!)

This assumes all layers are happy with a Byte() as the unit of
transmission, which I can immediately see is going to be a problem with
packet-based systems.

Finally, to transmit, Stack would take some input at the Application
level, run through each Layer's DecorateForTransmission in turn, then
call ... I dunno, ActuallyTransmit on the 'bottom' Layer; reverse the
process to receive...

Anyway, just some initial hand-wavy thoughts.

--
Larry Lard
Replies to group please

Hi Larry

I like the idea of a stack. I have just done a quick google and found some
interesting links, for example

http://www.eventhelix.com/RealtimeMa...atternCatalog/

has quite a few design patterns that look promising.

>> Also, the comms layer will probably need some kind of dynamic
>> configuration,
>> such as baud rate, stop bits, etc. How do we configure this layer? The
>> only
>> thing that has a handle to a TransportLayer object is the LinkLayer
>> object,
>> but the LinkLayer knows nothing of baud rates and stop bits. Where does
>> the
>> information come from? Do we have to pass it down the layers until the
>> object that understands the configuration gets it? That doesn't seem
>> right
>> at all.
>
> With the Stack model each generic and specific Layer is free to
> implement properties as required, so ApplicationLayer would implement
> Property FriendlyName, then DOOMLayer (Inherits ApplicationLayer) would
> always return "DOOM" for this property, and so on.

I'm not sure I follow you here. How does this help with the configuration of
the comms parameters required in the transport layer?

Charles


"Larry Lard" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
>
> Charles Law wrote:
>> This is going to seem like a basic OO question, but it comes up and bites
>> me
>> every now and again.
>>
>> Suppose we have a multi-tiered protocol to implement, what is the
>> logical,
>> OO way to design the handler? For example, let's say that we have to
>> implement the ISO 7-layer protocol, or something like an Allen-Bradley
>> master-slave protocol. At the lowest layer we might only need to top and
>> tail the data being transported, such as DLE STX [data from network
>> layer]
>> DLE ETX BCC.
>>
>> [data from network layer] might comprise DST SRC CMD STS TNS [data from
>> application layer]
>>
>> [data from application layer] might comprise FNC ADDR [data].
>>
>> We could have a class for each layer, where each contains an instance of
>> the
>> next layer down, e.g.
>>
>> Public Class ApplicationLayer
>>
>> Private m_NetworkLayer As NetworkLayer
>>
>> End Class
>>
>> Public Class NetworkLayer
>>
>> Private m_LinkLayer As LinkLayer
>>
>> End Class
>>
>> Public Class LinkLayer
>>
>> Private m_TransportLayer As TransportLayer
>>
>> End Class
>>
>> In the last case, TransportLayer could be a serial link implementation,
>> or
>> some other type of communications handler.
>>
>> Each layer would pass data on to the next layer down, and return results
>> to
>> the caller; the next layer up.
>>
>> Is this how other people would do it? I can't put my finger on why, but
>> there is something that just doesn't sit well with me about this method.
>> What if we want to dispense with the network layer? Do we have to change
>> the
>> code in ApplicationLayer to keep a local LinkLayer instance? Wouldn't
>> that
>> upset things a bit?
>
> This feels wrong to me because I don't see how containment correctly
> describes the relationship of layers to each other - they feel like
> siblings more than parents/children.
>
>
>>
>> I suppose each local instance should be based on a common interface, so
>> that
>> layers become, to some extent, interchangeable. Have I just answered my
>> own
>> question?
>
> How about this: A given scenario of layers is a Stack (I believe this
> term is the one used in networking). A Stack contains an *ordered* set
> of Layer objects. The base Layer class defines Transmit and Receive
> methods that operate on a <unit of transmission> - each specialization
> of Layer overrides as necessary.
>
> There are two levels of inheritance from Layer - for example for
> networking the first ('generic') level would be the 7 ISO levels,
> ApplicationLayer, TransportLayer, etc; then deriving from *those* would
> be *particular* ('specific') layers, eg TCP would derive from
> TransportLayer (assuming I've correctly remembered which ISO layer TCP
> maps to...)
>
>
>>
>> What if we want to change the comms layer to something else: does that
>> work
>> in the same way?
>>
>> Also, the comms layer will probably need some kind of dynamic
>> configuration,
>> such as baud rate, stop bits, etc. How do we configure this layer? The
>> only
>> thing that has a handle to a TransportLayer object is the LinkLayer
>> object,
>> but the LinkLayer knows nothing of baud rates and stop bits. Where does
>> the
>> information come from? Do we have to pass it down the layers until the
>> object that understands the configuration gets it? That doesn't seem
>> right
>> at all.
>
> With the Stack model each generic and specific Layer is free to
> implement properties as required, so ApplicationLayer would implement
> Property FriendlyName, then DOOMLayer (Inherits ApplicationLayer) would
> always return "DOOM" for this property, and so on.
>
>>
>> The same problem could occur in the network layer. An address is probably
>> required to ensure that the correct target gets the data, but where is
>> this
>> address managed?
>>
>> A lot of this is me just thinking out loud, but I would be interested in
>> other p
>
> What I haven't thought about at all is the <unit of transmission> - how
> about a Byte(), then you could have these methods on Layer (which is
> MustInherit):
>
> Public Function DecorateForTransmission(ToSend() As Byte) As Byte()
> Public Function UndecorateOnReception(Received() As Byte) As Byte()
>
> (shorter names in real thing!)
>
> This assumes all layers are happy with a Byte() as the unit of
> transmission, which I can immediately see is going to be a problem with
> packet-based systems.
>
> Finally, to transmit, Stack would take some input at the Application
> level, run through each Layer's DecorateForTransmission in turn, then
> call ... I dunno, ActuallyTransmit on the 'bottom' Layer; reverse the
> process to receive...
>
> Anyway, just some initial hand-wavy thoughts.
>
> --
> Larry Lard
> Replies to group please
>

Charles, i don't have too much advice for you, and i'm guessing you aren't
finding too many answers because something like a network protocol is
slightly esoteric compared to, say, accounting applications, but you were
right when you said you need an interface and Larry was right when he said
they're siblings, not kids

One of the main points of the ISO 7 layer model (which no one actually uses;
TCP is a 5 layer model, other protocols use their own design) is to divide
responsibility between function-specific items and have each of those exist
independently. You can then mix and match.

So to use the example of TCP, TCP can run on Ethernet and TokenRing. Each is
a different physical and link layer but the application layer is the same

TCP always runs on IP. Not sure if it has to, but i think it does (every
non-IP based TCP i've seen has run through a protocol converter or wrapper).
But you can certainly run other protocols on IP, UDP and ICMP being the most
common. So the top doesn't always control things

And you can add protocols to other protocols in a way the original never
intended. For example, NBT (NetBIOS over TCP) runs on TCP. And Microsoft's
SMB runs on NBT

So how is it that one person can add on top of something that was finished?
Or be able to swap out cables and wiring protocol and still have everything
run? As you mentioned earlier, it's setting well defined interfaces

So that's the theory. Not sure what you should specifically do. Depends on
specific problems i suppose. The whole "how a bill becomes a law" problem
might be achieved by looking at plugins and workflow. Maybe Facade and
Command objects, depending on what you're doing. But really, on a generic
level, you can get by with normal old code and interfaces

So here's an example i'm making up off the top of my head after not having
written network code for roughly a decade

SendNaughtyPicture(string address, Image naughtyPic) {
ApplicationProvider appProvider = Environment.getHandler(address);
ApplicationData data = appProvider.EncodeData(address, naughtyPic);
NetworkAddress netAddress = appProvider.getAddress(address);

NetworkProvider networkProvider = Environment.NetworkProvider;
networkProvider.Send(netAddress, data);
}

class NNTPProvider : ApplicationProvider
(i hate I on interface so it's AppProvider for me, not IApplicationProvider;
using pseudo-Hungarian seems so unobjecty not to mention ugly and Microsoft
doesn't consistently use it - see, for example, SHA1 - so i'm leaving it off)

class TCPIPNetworkProvider : NetworkProvider
(TCP is always referred to as TCPIP and not TCP because TCP can't live with
anything else - i think. IPv6 vs. IPv4 might be an exception. IP, on the
other hand, can live by itself just fine. Some interfaces are tightishly
coupled, some are not. i chose to use TCPIP so that users know that the two
layers are tied pretty closely)

TCPIPNetworkProvider::Send(string address, object data) {
//--- TCP is owned by a protocol stack so it asks it's controller
//--- who the implementer of the next layer is
Transporter transporter = this.ProtocolManager.Transporter;

TransportFrame[] frames = transporter.Packetizer.BreakItOnDown(data);

Window window = CreateWindow(frames);
for each (TransportFrame frame in window.Frames) {
transporter.Send(address, frame)
//--- Do something with ACKs, a feature of TCP but not IP
//--- This is actually probably event driven so you wouldn't see it in
//--- a routine exactly like this
}
}

IPTransportProvider::Send(string address, object data) {
//--- IP is owned by a protocol stack so it asks it's controller
//--- who the implementer of the next layer is
PhysicalTransporter transporter = this.ProtocolManager.PhysicalTransporter;

transporter.Send(address, data);
}

And so on and so on

i don't know if that's the best way to do it but it's a way to start, a
discussion if nothing else. Lots of interfaces to keep the bindings down a
little. Layers still know what interfaces they talk to. Factories provide the
proper implementer of the interface. Where that factory is depends

Suppose you use a Web browser to talk archie over TCP/IP over Conrad
enhanced token ring over 100MB cable. What are your groupings and who are
your providers?
- Browser.
An app you run
- Gopher.
Windows tells Browser who to talk to talk gopher
- TCP/IP.
TCP stack tells TCP and IP where to find each other. Might be
different DLLs, might be the same
- Conrad 100MB Token Ring.
Windows tells TCP/IP stack what wire protocol this computer speaks
and where to find the provider/DLL that will do this
- 100MB Token Ring Cable.
Conrad Token Ring DLL knows how to tell what type of wire is hooked up,
what line-level protocol to use with each and where to get the provider
for each, be it in another DLL or in the same one

Don't know if that helps, but i've got my fingers crossed

Charles,

I did not understand where you were talking about and than Baylor brought me
back on earth.

It is simple the ISO-OSI model. From which as Baylor says in my opinion
correct that everybody told they had implemented it, only with some main
functionality in different layers.

If you want to create something as that, than I come back to the word about
you and what your English ones learned me again. "Queues". Or as I and
probably Larry calls it. "FIFO stacks" (which does not exist). I write this
because now I understand Larry's answer as well and was first thinking that
you had to use named pipes.

It again a very while ago I was busy with it, however for me basicly it is
based on a package model. Where every packed get/add a prefix to a lower
level (one level has that not, I don't know which). Because of what Baylor
and now I wrote that everybody implement it in another way. Are the names
very confusing, because some are doing things on other levels. (As far as I
remember me is IPX very different from this model).

I find it mostly more cosmetic using the names. Although the package/layer
system we find back in every modern datacom system.

Just my thought, maybe it adds something.

Cor

Hi Baylor

Thanks for the detailed response. Plenty of food for thought; lots of stuff
I hadn't considered, and new ideas (to me).

I'm off to muse.

Cheers

Charles


"baylor" <(E-Mail Removed)> wrote in message
news:A06139FF-116C-49D9-8D84-(E-Mail Removed)...
> Charles, i don't have too much advice for you, and i'm guessing you aren't
> finding too many answers because something like a network protocol is
> slightly esoteric compared to, say, accounting applications, but you were
> right when you said you need an interface and Larry was right when he said
> they're siblings, not kids
>
> One of the main points of the ISO 7 layer model (which no one actually
> uses;
> TCP is a 5 layer model, other protocols use their own design) is to divide
> responsibility between function-specific items and have each of those
> exist
> independently. You can then mix and match.
>
> So to use the example of TCP, TCP can run on Ethernet and TokenRing. Each
> is
> a different physical and link layer but the application layer is the same
>
> TCP always runs on IP. Not sure if it has to, but i think it does (every
> non-IP based TCP i've seen has run through a protocol converter or
> wrapper).
> But you can certainly run other protocols on IP, UDP and ICMP being the
> most
> common. So the top doesn't always control things
>
> And you can add protocols to other protocols in a way the original never
> intended. For example, NBT (NetBIOS over TCP) runs on TCP. And Microsoft's
> SMB runs on NBT
>
> So how is it that one person can add on top of something that was
> finished?
> Or be able to swap out cables and wiring protocol and still have
> everything
> run? As you mentioned earlier, it's setting well defined interfaces
>
> So that's the theory. Not sure what you should specifically do. Depends on
> specific problems i suppose. The whole "how a bill becomes a law" problem
> might be achieved by looking at plugins and workflow. Maybe Facade and
> Command objects, depending on what you're doing. But really, on a generic
> level, you can get by with normal old code and interfaces
>
> So here's an example i'm making up off the top of my head after not having
> written network code for roughly a decade
>
> SendNaughtyPicture(string address, Image naughtyPic) {
> ApplicationProvider appProvider = Environment.getHandler(address);
> ApplicationData data = appProvider.EncodeData(address, naughtyPic);
> NetworkAddress netAddress = appProvider.getAddress(address);
>
> NetworkProvider networkProvider = Environment.NetworkProvider;
> networkProvider.Send(netAddress, data);
> }
>
> class NNTPProvider : ApplicationProvider
> (i hate I on interface so it's AppProvider for me, not
> IApplicationProvider;
> using pseudo-Hungarian seems so unobjecty not to mention ugly and
> Microsoft
> doesn't consistently use it - see, for example, SHA1 - so i'm leaving it
> off)
>
> class TCPIPNetworkProvider : NetworkProvider
> (TCP is always referred to as TCPIP and not TCP because TCP can't live
> with
> anything else - i think. IPv6 vs. IPv4 might be an exception. IP, on the
> other hand, can live by itself just fine. Some interfaces are tightishly
> coupled, some are not. i chose to use TCPIP so that users know that the
> two
> layers are tied pretty closely)
>
> TCPIPNetworkProvider::Send(string address, object data) {
> //--- TCP is owned by a protocol stack so it asks it's controller
> //--- who the implementer of the next layer is
> Transporter transporter = this.ProtocolManager.Transporter;
>
> TransportFrame[] frames = transporter.Packetizer.BreakItOnDown(data);
>
> Window window = CreateWindow(frames);
> for each (TransportFrame frame in window.Frames) {
> transporter.Send(address, frame)
> //--- Do something with ACKs, a feature of TCP but not IP
> //--- This is actually probably event driven so you wouldn't see it in
> //--- a routine exactly like this
> }
> }
>
> IPTransportProvider::Send(string address, object data) {
> //--- IP is owned by a protocol stack so it asks it's controller
> //--- who the implementer of the next layer is
> PhysicalTransporter transporter =
> this.ProtocolManager.PhysicalTransporter;
>
> transporter.Send(address, data);
> }
>
> And so on and so on
>
> i don't know if that's the best way to do it but it's a way to start, a
> discussion if nothing else. Lots of interfaces to keep the bindings down a
> little. Layers still know what interfaces they talk to. Factories provide
> the
> proper implementer of the interface. Where that factory is depends
>
> Suppose you use a Web browser to talk archie over TCP/IP over Conrad
> enhanced token ring over 100MB cable. What are your groupings and who are
> your providers?
> - Browser.
> An app you run
> - Gopher.
> Windows tells Browser who to talk to talk gopher
> - TCP/IP.
> TCP stack tells TCP and IP where to find each other. Might be
> different DLLs, might be the same
> - Conrad 100MB Token Ring.
> Windows tells TCP/IP stack what wire protocol this computer speaks
> and where to find the provider/DLL that will do this
> - 100MB Token Ring Cable.
> Conrad Token Ring DLL knows how to tell what type of wire is hooked up,
> what line-level protocol to use with each and where to get the provider
> for each, be it in another DLL or in the same one
>
> Don't know if that helps, but i've got my fingers crossed

Hi Cor

You are right that I was describing the ISO-OSI model, but as you can
probably guess I did not tell it exactly as it is. I am actually
implementing GPIB (IEEE 488) to control a remote device, but I used ISO-OSI
in my example because I thought it would be more commonly used. I also have
to do it in VB6 (but that's my problem).

Anyway, I have some good ideas now.

Regards

Charles


"Cor Ligthert" <(E-Mail Removed)> wrote in message
news:OZ%(E-Mail Removed)...
> Charles,
>
> I did not understand where you were talking about and than Baylor brought
> me back on earth.
>
> It is simple the ISO-OSI model. From which as Baylor says in my opinion
> correct that everybody told they had implemented it, only with some main
> functionality in different layers.
>
> If you want to create something as that, than I come back to the word
> about you and what your English ones learned me again. "Queues". Or as I
> and probably Larry calls it. "FIFO stacks" (which does not exist). I write
> this because now I understand Larry's answer as well and was first
> thinking that you had to use named pipes.
>
> It again a very while ago I was busy with it, however for me basicly it is
> based on a package model. Where every packed get/add a prefix to a lower
> level (one level has that not, I don't know which). Because of what Baylor
> and now I wrote that everybody implement it in another way. Are the names
> very confusing, because some are doing things on other levels. (As far as
> I remember me is IPX very different from this model).
>
> I find it mostly more cosmetic using the names. Although the package/layer
> system we find back in every modern datacom system.
>
> Just my thought, maybe it adds something.
>
> Cor
>