Question:

How should orb packet srcnames be chosen?

Answer:

The orbserver is largely indifferent to how packet srcnames are chosen, although any particular running orbserver has a fixed limit on the number of different srcnames it will allow.

However, srcnames fill two important roles:

• They provide the means for separating the packets in

an orb into different piles, based on regular expressions. Some simple examples of this might be getting all the packets for a particular station, or all the packets for a given channel orientation.

• Packet srcnames must specify the content format (the unstuff

routine in the Pkt library), at least if standard programs are to be able to use them.

Because the srcname typically includes the network, station, and often the channel, this information is usually not included in the packet itself, as a space saving gesture.

We have a convention for srcnames, and this convention is built into the Pkt library. The form of a srcname is:

net_sta_chan_loc/type/subcode

The net_sta_chan_loc indicates the origin of the packet, and may be shortened to eliminate loc, chan, sta and net in cases where it is unnecessary (loc), non-unique (chan in packets containing multiple channels), or understood (net in /db database packets or /pf parameter file packets). (The separating underscores are eliminated also).

The type code is used by the Pkt library to look up the unstuff routine. If it's not present, the Pkt library is unable to unstuff it and most standard programs will not be able to process it. Some may complain bitterly, others may ignore such packets.

The subcode is discretionary. It is used as needed, to further discriminate between packets.

There is a detailed discussion on srcname conventions in the Dataflow Within Antelope document that can be found in $ANTELOPE/doc/dataflow.pdf