Use IPC
Send signed transaction bytes to the local agent with a standalone C example.
IPC lets your application submit to an agent on the same Linux host through shared memory. Start with the standalone C example below. Use the optional wire reference when writing your own client.
Requirements
- The agent is running with
listen.ipc = "/run/swqos/swqos.sock", or another explicit socket path. - Your application runs as
swqosor belongs to its group. After adding group membership, restart the application. See IPC access. - You have a signed transaction with a valid blockhash and the required tip. Fetch current tip accounts through the agent's
getTipAccounts.
Download the example
Download swqos-ipc-send.cBuild it on Linux x86_64 with GCC or Clang:
cc -std=c11 -O2 -Wall -Wextra -o swqos-ipc-send swqos-ipc-send.cThe program sends one transaction, requests a reply, waits up to five seconds and exits. It does not construct or sign the transaction.
Connect and submit
Save the signed transaction's raw wire bytes in a file. If you have base64 text, decode it first:
base64 --decode signed-transaction.b64 > signed-transaction.bin
./swqos-ipc-send /run/swqos/swqos.sock signed-transaction.binUse the path from listen.ipc if yours differs. Run the command as an account with socket access.
Other submissions
The example sends a transaction with a reply and without preflight. A custom client can also send bundles, request transaction preflight or declare a tip using the payload envelope. Arrange declared-tip billing with support before using declarations.
For custom clients, use reply flag 0x01 while integrating so you can see refusals. The submission reference defines the record kinds and flags.
Read the reply
An accepted transaction prints:
code 0The program exits with status 0 only for an accepted reply. For a refusal, it prints a nonzero reply code and any JSON error detail, then exits with status 1. Use the detail's reason to find the fix in Errors.
Acceptance is not confirmation. Check the transaction signature with your Solana RPC provider. A timeout, disconnection or rejection can leave the outcome uncertain; check the signature before sending a replacement.
Reconnect and troubleshoot
An agent stop or automatic update closes the session. A long-running client must open a new socket and repeat the handshake before sending again. Do not reuse the old mapping or automatically replay requests whose outcomes are unknown.
| Problem | What to check |
|---|---|
connect: No such file or directory | The agent is running and the socket path matches listen.ipc |
connect: Permission denied | Your account has socket access and the client was restarted after a group change |
connect: Connection refused | A running agent is listening at the path |
no completion within 5 seconds | Check the signature and service log before retrying |
| Session ends immediately after a custom submission | Check the record and ring rules |
For long-running clients, keep draining completions and match them by request ID, not arrival order. Set a timeout for every request. See IPC troubleshooting for missing replies and busy polling for CPU use.