FreeCalypso > hg > freecalypso-sw
comparison 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 |
comparison
equal
deleted
inserted
replaced
| 175:2f214bd03119 | 176:7f727aaf5cd4 |
|---|---|
| 1 /* | |
| 2 * This header defines and describes (through comments) the local UNIX domain | |
| 3 * socket interface implemented between rvinterf and its clients like fc-tmsh. | |
| 4 * | |
| 5 * The UNIX domain sockets used for this ad hoc interface are of the | |
| 6 * SOCK_STREAM kind, but the true nature of the communication is message-based. | |
| 7 * We use the same trick that is used for DNS over TCP: every message in each | |
| 8 * direction is preceded by a 2-byte length. This length and all other | |
| 9 * multibyte numbers are sent in the native byte order of the machine on which | |
| 10 * the rvinterf suite is running. The limit on the size of these messages | |
| 11 * (for sizing buffers etc) is: | |
| 12 */ | |
| 13 | |
| 14 #define LOCALSOCK_MAX_MSG 1024 | |
| 15 | |
| 16 /* | |
| 17 * Each message in the client->rvinterf direction (can be seen as command) | |
| 18 * begins (after the length) with an opcode byte as follows: | |
| 19 */ | |
| 20 | |
| 21 #define CLI2RVI_WANT_RVTRACE 0x00 | |
| 22 #define CLI2RVI_WANT_MUXPROTO 0x01 | |
| 23 #define CLI2RVI_PKT_TO_TARGET 0x02 | |
| 24 #define CLI2RVI_RAWBYTES_TO_TARGET 0x03 | |
| 25 | |
| 26 /* | |
| 27 * The first two commands (CLI2RVI_WANT_RVTRACE and CLI2RVI_WANT_MUXPROTO) | |
| 28 * are the means by which client programs inform rvinterf that they are | |
| 29 * interested in receiving copies of certain packets coming from the target. | |
| 30 * | |
| 31 * The CLI2RVI_WANT_RVTRACE opcode needs to be followed by a USEID mask value | |
| 32 * and a USEID match value, both in the native byte order of the machine | |
| 33 * running rvinterf, for a total message length of 9 bytes. For every RV | |
| 34 * trace message received from the target, rvinterf will iterate through all | |
| 35 * active clients to see who is interested: if the received USEID ANDed with | |
| 36 * the mask equals the match value, the message will be forwarded to that | |
| 37 * client. | |
| 38 * | |
| 39 * The CLI2RVI_WANT_MUXPROTO opcode needs to be followed by one byte | |
| 40 * identifying the RVTMUX protocol of interest, i.e., the first byte of the | |
| 41 * packets exchanged between the host and the target, e.g., 0x12 for L1 traces | |
| 42 * as defined in pktmux.h, for a total message length of 2 bytes. | |
| 43 * | |
| 44 * The last two commands (CLI2RVI_PKT_TO_TARGET and CLI2RVI_RAWBYTES_TO_TARGET) | |
| 45 * cause data payload to be sent to the target serial port. Payload following | |
| 46 * CLI2RVI_PKT_TO_TARGET (must not exceed MAX_PKT_TO_TARGET) is sent with the | |
| 47 * proper packet encapsulation per TI; bytes following | |
| 48 * CLI2RVI_RAWBYTES_TO_TARGET are sent raw. | |
| 49 */ | |
| 50 | |
| 51 /* | |
| 52 * Each message in the rvinterf->client direction begins (after the length) | |
| 53 * with a message type byte as follows: | |
| 54 */ | |
| 55 | |
| 56 #define RVI2CLI_PKT_FROM_TARGET 0x00 | |
| 57 #define RVI2CLI_LOCAL_CMD_RESP 0x01 | |
| 58 | |
| 59 /* | |
| 60 * Messages beginning with RVI2CLI_PKT_FROM_TARGET are packets received | |
| 61 * from the target GSM device; the byte following this type code is the | |
| 62 * first byte of the packet from the target, e.g., 0x11 for RV traces or | |
| 63 * 0x12 for L1 traces. Rvinterf will only start sending these messages | |
| 64 * to a client after that client has expressed interest in receiving | |
| 65 * target->host packets of a particular type. | |
| 66 * | |
| 67 * Messages beginning with RVI2CLI_LOCAL_CMD_RESP are generated locally | |
| 68 * by rvinterf itself as responses to commands, currently as responses to | |
| 69 * CLI2RVI_WANT_{RVTRACE,MUXPROTO}. The byte following the | |
| 70 * RVT2CLI_LOCAL_CMD_RESP type code is ASCII '+' or ASCII '-', indicating | |
| 71 * success or error, respectively. Any remaining bytes form a message | |
| 72 * for the user. | |
| 73 */ |
