General talk about software patterns

[Jesús Alonso <kenchoweb AT hotmail.com>]

I personally would parse the header, or at least the first bytes with a 
common receiver, to detect which protocol it is, and then switch to the 
apropiate strategy. Using some byte(s) at the beginning to identify the 
message protocol would solve this problem.

Regards,
 Jesús Alonso

> just curious,
>
> I agree that handling protocols could be done by strategy, but before
> getting the protocol objects, the raw messages need to be parsed.
> Suppose the message are among:
>
> AABBBBBBCCC
> XXBBBBCCC
> DDBBBBCCC
>
> The first part is header containing length of its body and some
> protocol informations, the middle is body, the tail is its crc data.
>
> My question is how to parse the raw messages to their corresponding
> protocol objects, in a maintainable way ?
>
> thanks.
> kem.
>
> On 10/3/05, Jesús Alonso 
> <kenchoweb AT hotmail.com>
>  wrote:
> > Hello Andre.
> >
> > Okay, let me see if I understood correctly. You are implementing some 
> kind
> > of communication protocols, and want the protocol management to be done 
> by
> > classes/objects, right? So your question is which pattern(s) are more
> > suitable for that purpose. Please, correct me if I'm wrong.
> >
> > This is the solution I see. Protocols to be managed by Strategies (also
> > known as Policies). States are used for small state machines that 
> determine
> > some kind of object behavior, but through complex state changing. 
> Strategies
> > are more oriented to complete "packages" of routines (thus the name of
> > Policy, which in this case could be replaced by Protocol). So, to me, 
> the
> > solution would be implementing the protocols as strategies.
> >
> > About the problem of code duplication/sharing between protocols, you 
> could
> > decouple those routines to a different class, using the Bridge pattern. 
> This
> > way, protocol data interpretation, for instance, could be independent of 
> the
> > way chunk starts are detected, for instance. If you can give me a 
> concrete
> > example of routines that will be shared between protocols, I could give 
> you
> > a more precise example.
> >
> > Hope that helps.
> >
> > Regards,
> >   Jesús Alonso
> >
> > >
> > >Hi there,
> > >
> > >I have a question about what type of Pattern might best fit an
> > >application.  Here is a synopsis:
> > >
> > >We have embedded software that can access several types of "receivers"
> > >that all transmit data over a serial port.  Many of the receivers use
> > >the same protocol, but some use a different protocol.  By protocol I
> > >mean that they have different control bytes signaling the beginning
> > >and end of the message, and different header contents that usually
> > >specify A) the message type and B) the message data length.
> > >
> > >So basically a message always looks like this, regardless of the 
> protocol:
> > >
> > >Message "Start" qualifier
> > >Message Header, including message type and length
> > >Message Data, which includes data formatted for a message type.
> > >
> > >So basically, the message is unpacked and then sent to a handler
> > >routine based on the message type, if the message is valid (each
> > >message is typically checksummed or CRCd to determine this within the
> > >protocol).
> > >
> > >Another part of the story is that, the receivers that use the same
> > >protocol also handle none, some or most of the same message types, but
> > >the message types that they handle depend on the application.
> > >
> > >The code is a mess right now and I can't post any of it for reasons I
> > >cannot supply.  Basically it comes down what I see as a state pattern
> > >for the protocol:
> > >
> > >Look for message start.
> > >Message start received, look for message header.
> > >Message header valid, look for data.
> > >Data valid, process the message based on the message header.
> > >- Any step that fails, look for a new message start.
> > >
> > >I was also considering strategy, because how the code goes about
> > >looking for a message start, etc. differs per protocol.
> > >
> > >In terms of handling the messages, if I created some kind of receiver
> > >class full of routines to handle each message sent by the receiver,
> > >there would be some code duplication because different receivers
> > >sometimes handle the same messages in the same exact way.
> > >
> > >I hope this email is complete enough and/or the problem common enough
> > >for someone to suggest a solution.  Right now we are using #ifdefs in
> > >very structured code to handle each receiver in its unique fashion,
> > >and its not pretty.
> > >
> > >Thanks,
> > >
> > >Andre
> > >
> > >_______________________________________________
> > >patterns-discussion mailing list
> > 
> >patterns-discussion AT cs.uiuc.edu
> > >http://lists.cs.uiuc.edu/mailman/listinfo/patterns-discussion
> >
> >
> > _______________________________________________
> > patterns-discussion mailing list
> > 
> patterns-discussion AT cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/patterns-discussion
> >
>
>
> --
> do you know why MAC is no as fast as PC ?
> It's because the company doesn't focus only on
> computers or electronic equipments.They also
> sell burgers and fry.
>
> _______________________________________________
> patterns-discussion mailing list
> patterns-discussion AT cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/patterns-discussion