How to Implement a Tiered Protocol; Design Pattern?

[Charles Law]

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 ApplicationLaye r

Private m_NetworkLayer As NetworkLayer

End Class

Public Class NetworkLayer

Private m_LinkLayer As LinkLayer

End Class

Public Class LinkLayer

Private m_TransportLaye r 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 ApplicationLaye r 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

[Larry Lard]

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 ApplicationLaye r

Private m_NetworkLayer As NetworkLayer

End Class

Public Class NetworkLayer

Private m_LinkLayer As LinkLayer

End Class

Public Class LinkLayer

Private m_TransportLaye r 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 ApplicationLaye r 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,
ApplicationLaye r, 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 ApplicationLaye r would implement
Property FriendlyName, then DOOMLayer (Inherits ApplicationLaye r) 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 DecorateForTran smission(ToSend () As Byte) As Byte()
Public Function UndecorateOnRec eption(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 DecorateForTran smission in turn, then
call ... I dunno, ActuallyTransmi t on the 'bottom' Layer; reverse the
process to receive...

Anyway, just some initial hand-wavy thoughts.

--
Larry Lard
Replies to group please

[Charles Law]

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 ApplicationLaye r would implement
Property FriendlyName, then DOOMLayer (Inherits ApplicationLaye r) 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" <la*******@hotm ail.com> wrote in message
news:11******** *************@o 13g2000cwo.goog legroups.com...

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 ApplicationLaye r

Private m_NetworkLayer As NetworkLayer

End Class

Public Class NetworkLayer

Private m_LinkLayer As LinkLayer

End Class

Public Class LinkLayer

Private m_TransportLaye r 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 ApplicationLaye r 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,
ApplicationLaye r, 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 ApplicationLaye r would implement
Property FriendlyName, then DOOMLayer (Inherits ApplicationLaye r) 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 DecorateForTran smission(ToSend () As Byte) As Byte()
Public Function UndecorateOnRec eption(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 DecorateForTran smission in turn, then
call ... I dunno, ActuallyTransmi t on the 'bottom' Layer; reverse the
process to receive...

Anyway, just some initial hand-wavy thoughts.

--
Larry Lard
Replies to group please

[baylor]

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

SendNaughtyPict ure(string address, Image naughtyPic) {
ApplicationProv ider appProvider = Environment.get Handler(address );
ApplicationData data = appProvider.Enc odeData(address , naughtyPic);
NetworkAddress netAddress = appProvider.get Address(address );

NetworkProvider networkProvider = Environment.Net workProvider;
networkProvider .Send(netAddres s, data);
}

class NNTPProvider : ApplicationProv ider
(i hate I on interface so it's AppProvider for me, not IApplicationPro vider;
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 TCPIPNetworkPro vider : 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)

TCPIPNetworkPro vider::Send(str ing 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.ProtocolMa nager.Transport er;

TransportFrame[] frames = transporter.Pac ketizer.BreakIt OnDown(data);

Window window = CreateWindow(fr ames);
for each (TransportFrame frame in window.Frames) {
transporter.Sen d(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
}
}

IPTransportProv ider::Send(stri ng address, object data) {
//--- IP is owned by a protocol stack so it asks it's controller
//--- who the implementer of the next layer is
PhysicalTranspo rter transporter = this.ProtocolMa nager.PhysicalT ransporter;

transporter.Sen d(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

[Cor Ligthert]

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

[Charles Law]

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" <ba****@discuss ions.microsoft. com> wrote in message
news:A0******** *************** ***********@mic rosoft.com...

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

SendNaughtyPict ure(string address, Image naughtyPic) {
ApplicationProv ider appProvider = Environment.get Handler(address );
ApplicationData data = appProvider.Enc odeData(address , naughtyPic);
NetworkAddress netAddress = appProvider.get Address(address );

NetworkProvider networkProvider = Environment.Net workProvider;
networkProvider .Send(netAddres s, data);
}

class NNTPProvider : ApplicationProv ider
(i hate I on interface so it's AppProvider for me, not
IApplicationPro vider;
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 TCPIPNetworkPro vider : 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)

TCPIPNetworkPro vider::Send(str ing 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.ProtocolMa nager.Transport er;

TransportFrame[] frames = transporter.Pac ketizer.BreakIt OnDown(data);

Window window = CreateWindow(fr ames);
for each (TransportFrame frame in window.Frames) {
transporter.Sen d(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
}
}

IPTransportProv ider::Send(stri ng address, object data) {
//--- IP is owned by a protocol stack so it asks it's controller
//--- who the implementer of the next layer is
PhysicalTranspo rter transporter =
this.ProtocolMa nager.PhysicalT ransporter;

transporter.Sen d(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 Law]

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" <no************ @planet.nl> wrote in message
news:OZ******** ********@TK2MSF TNGP14.phx.gbl. ..

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