General talk about software patterns

[jdeena AT comcast.net]

Would ANTLR(www.antlr.org)  solve your problem to generate parser for your messages and grammar to message need to be maintained which I woud think easy to maintain?

Parser generated  by ANTLR can be used tointerprete the message, modify the behavior of the parser on how tointerprete themessagee by modifying thegrammarr

and re-generate the parser.

Regards,

Deena

 

> -------------- Original message -------------- 
>
> > 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 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 in!
>  terpretation, 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 ex!
>  act 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 t
> he 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