Re: how to store list of varying types

See below...
On Mon, 30 Jun 2008 09:50:34 -0700, "Nick Schultz" <nick.schultz@flir.com>
wrote:


****
Correct. What you could do is store it as a data structure

<packettype> <totallength> <rawbytetype>
<totallength><rawbyte0>...<rawbyten>
<type0><offset0><type1offset1>...<typen><offsetn>

Just send these out. There are some interesting questions, such as why
you need the data
preparsed (couldn't each receiver just call a parsing subroutine?); you
could just send
the raw data out. Since the packet type implicitly indicates what the
offsets would be,
you could just define a union member

typedef struct {
               WORD count;
               BYTE flags; } TYPE0;
typedef struct {
               DWORD count;
               WORD thing;
               BYTE flags;
               WORD whatever; } TYPE1;

typedef struct {
      BYTE header;
      union {
              TYPE0 type0;
              TYPE1 type1;
               ...
              TYPEn typen;
             } t;
  } data;

then, when you receive the packet, you just map the data union onto it,
e.g.,

LRESULT CMyWhatever::OnCopyData(WPARAM wParam, LPARAM lParam)
    {
     data * stuff = (data *)...address of byte in data packet...;
     switch(stuff->header)
           {
            case TYPE0:
                   HandleType0(&data->t.type0);
                   break;
            case TYPE1:
                   HandleType1(&data->t.type1);
                   break;
            ...
            default: // unknown type
                    return 0;
           }
     }

void CMyWhatever::HandleType0(TYPE0 * info)
  {
   ...do stuff
  }

void CMyWhatever::HandleType1(TYPE1 * info)
  {
   ...do stuff
  }

etc. I used neutral names like type0, type1, etc. but for one of my
embedded systems the
types might have been

RAWDATAPACKET, CONTROLPACKET, VALUEPACKET, TIMERPACKET, SWITCHPACKET, and
similar
meaningful names.

I don't know what your specific protocol is, but in the embedded protocols
I've worked in,
there is ALWAYS a structure, so there should be no reason to create a
vector that
represents pieces that are "preparsed". You know the type, which tells
you the structure,
and you interpret the data relative to that structure, nothing else fancy
required.

etc.

Essentially, you are talking about trivial amounts of data, so the notion
of copying
becomes irrelevant for performance.
****


*****
800 messages/sec is about 1.25ms/msg. Since an 2.8GHz x86 can peak out at
6instructions/ns, you have time to issue over 7 million instructions
between each message.
That's a lot of headroom.

But note that Windows makes no pretensions about being a realtime system.
With a
messaging system vastly less efficient than the one you are proposing, I
could handle
1400messages/sec each of which involved complex processing

Since this is an early project, one question is: is your background
Unix/linux? It is a
natural decomposition in Unix/linux to think of "processes", but have you
simply
considered "threads"?
****


****
It might not be a good idea. A Windows service cannot easily communicate
with
applications. You would have to export named pipes from the service and
send data out the
named pipes to get the information distributed. That's the only effective
way to
communicate with a service. It cannot use SendMessage/PostMessage to
applications running
as the logged-in user.

I would suggest the on-the-fly pipe allocation mechanism where a new pipe
is created each
time a connection is established.
joe
****


Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm