Design recommendation wanted.

From: Yannick Turgeon (nobody_at_nowhere.com)
Date: 09/24/04


Date: Thu, 23 Sep 2004 19:29:25 -0400

Hello all,

I'm implementing a protocol to communicate with a server through serial port
(Yes Peter and Alex it's me again!). This means looking for lost packet,
checksum error, connection failure.

Whitout error, the normal course of things is:
(C = Client - the one I'm programming, S = Server)

Type #1 command:
C: Send a packet to ask something
S: Reply with the final answer
C: Acknowledge reception

Type #2 command:
C: Send a packet to ask something
S: Reply with part of the answer
C: Acknowledge reception of the partial answer
S: Reply with the following part of the answer
C: Acknowledge reception of the partial answer
...
S: Confirm the end of the answer
C: Acknowledge reception

Added to that, the server can send me an error packet due to my last sent
packet being lost or checksum error or packet wrongly construct or
impossibility to answer my "correctly constructed and received question".
It includs in this error whether or not I should resend the last packet.
Even more, there is a fixed maximum number of tentative to resent a packet.

So my question is a general design one:
Anybody has any hint how to handle in a well structured way that much
possible errors and situation? How?

Say I got 20 commands I can ask to server (which is near the real
situation).

I tried to make a base Command class that has a function that looks like:

def getReply(expected):
  try:
    packet = serial.readline() #raise TimeoutError()
    packet_type, data = decode(packet) #raise FormatPacketError()
                                        # ChecksumError()
                                        # PacketNumberError()
    if packet_type == ERROR:
        raise ServerReplyError()
    if packet_type <> expected:
        raise UnexpectedPacketError()
    c = PACKETS[packet_type](data) #PACKETS is a dict containing Classes
                                    #raise DataFormatError()
  expect TimeoutError:
    blabla
  expect FormatPacketError:
    blabla
  expect ChecksumError:
    blabla
  expect PacketNumberError:
    blabla
  expect UnexpectedPacketError:
    blabla
  expect ServerReplyError:
    blabla
  expect DataFormatError:
    blabla

With this solution, I will get lost very soon. I feel that I would need a
kind of State-Managing system/class that would keep track of the command
processing in general. But I'm not grasping it. I'm conscious that by not
knowing the total situation, it's difficult for anybody to help but any
suggestion, recommendation would be much appreciated.

Yannick



Relevant Pages

  • [REVS] Backdoor Spotcom Analysis
    ... Spotcom is a backdoor client application that allows a hacker to control ... The server IP address is hard-coded in ... msrsvp.exe accepts a couple of command line arguments. ... the packet payload. ...
    (Securiteam)
  • Re: tool to interpret packets? and Qs about lineout!
    ... > not as far as packet format and types are concerned. ... Referring to an input command which 'could' have been issued to ... the server which end with a request for the ... it is possible to implement the Kermit protocol itself in a Kermit ...
    (comp.protocols.kermit.misc)
  • Re: how to handle socket timeout?
    ... If you can set up a new connection to it, ... sending a 'version' command will have the ... The server gets the query and starts working on it. ... ever send you a packet, nor do you have any reason to send the server ...
    (comp.unix.programmer)
  • dnscmd not reconized
    ... Event Source: DNS ... The DNS server encountered a bad packet from 10.3.48.252. ... When I run the same command on the other server I receive this message. ...
    (microsoft.public.windows.server.dns)
  • [PATCH 19-rc2] Fix misc .c/.h comment typos
    ... Implements an interface for i2c compatible eeproms to run under linux. ... Changed struct initializer syntax to the currently preferred notation ... ** Packet is an actual packet structure to be filled in with the packet ... -** as the command processore doesn't process the command packet in any way. ...
    (Linux-Kernel)