diff rvinterf/localsock.h @ 176:7f727aaf5cd4

rvinterf: beginning of server implementation
author Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
date Sat, 23 Nov 2013 07:40:13 +0000
parents
children 7ab6b29e76bb
line wrap: on
line diff
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/rvinterf/localsock.h	Sat Nov 23 07:40:13 2013 +0000
@@ -0,0 +1,73 @@
+/*
+ * This header defines and describes (through comments) the local UNIX domain
+ * socket interface implemented between rvinterf and its clients like fc-tmsh.
+ *
+ * The UNIX domain sockets used for this ad hoc interface are of the
+ * SOCK_STREAM kind, but the true nature of the communication is message-based.
+ * We use the same trick that is used for DNS over TCP: every message in each
+ * direction is preceded by a 2-byte length.  This length and all other
+ * multibyte numbers are sent in the native byte order of the machine on which
+ * the rvinterf suite is running.  The limit on the size of these messages
+ * (for sizing buffers etc) is:
+ */
+
+#define	LOCALSOCK_MAX_MSG	1024
+
+/*
+ * Each message in the client->rvinterf direction (can be seen as command)
+ * begins (after the length) with an opcode byte as follows:
+ */
+
+#define	CLI2RVI_WANT_RVTRACE		0x00
+#define	CLI2RVI_WANT_MUXPROTO		0x01
+#define	CLI2RVI_PKT_TO_TARGET		0x02
+#define	CLI2RVI_RAWBYTES_TO_TARGET	0x03
+
+/*
+ * The first two commands (CLI2RVI_WANT_RVTRACE and CLI2RVI_WANT_MUXPROTO)
+ * are the means by which client programs inform rvinterf that they are
+ * interested in receiving copies of certain packets coming from the target.
+ *
+ * The CLI2RVI_WANT_RVTRACE opcode needs to be followed by a USEID mask value
+ * and a USEID match value, both in the native byte order of the machine
+ * running rvinterf, for a total message length of 9 bytes.  For every RV
+ * trace message received from the target, rvinterf will iterate through all
+ * active clients to see who is interested: if the received USEID ANDed with
+ * the mask equals the match value, the message will be forwarded to that
+ * client.
+ *
+ * The CLI2RVI_WANT_MUXPROTO opcode needs to be followed by one byte
+ * identifying the RVTMUX protocol of interest, i.e., the first byte of the
+ * packets exchanged between the host and the target, e.g., 0x12 for L1 traces
+ * as defined in pktmux.h, for a total message length of 2 bytes.
+ *
+ * The last two commands (CLI2RVI_PKT_TO_TARGET and CLI2RVI_RAWBYTES_TO_TARGET)
+ * cause data payload to be sent to the target serial port.  Payload following
+ * CLI2RVI_PKT_TO_TARGET (must not exceed MAX_PKT_TO_TARGET) is sent with the
+ * proper packet encapsulation per TI; bytes following
+ * CLI2RVI_RAWBYTES_TO_TARGET are sent raw.
+ */
+
+/*
+ * Each message in the rvinterf->client direction begins (after the length)
+ * with a message type byte as follows:
+ */
+
+#define	RVI2CLI_PKT_FROM_TARGET		0x00
+#define	RVI2CLI_LOCAL_CMD_RESP		0x01
+
+/*
+ * Messages beginning with RVI2CLI_PKT_FROM_TARGET are packets received
+ * from the target GSM device; the byte following this type code is the
+ * first byte of the packet from the target, e.g., 0x11 for RV traces or
+ * 0x12 for L1 traces.  Rvinterf will only start sending these messages
+ * to a client after that client has expressed interest in receiving
+ * target->host packets of a particular type.
+ *
+ * Messages beginning with RVI2CLI_LOCAL_CMD_RESP are generated locally
+ * by rvinterf itself as responses to commands, currently as responses to
+ * CLI2RVI_WANT_{RVTRACE,MUXPROTO}.  The byte following the
+ * RVT2CLI_LOCAL_CMD_RESP type code is ASCII '+' or ASCII '-', indicating
+ * success or error, respectively.  Any remaining bytes form a message
+ * for the user.
+ */