Crunch CRiSP File Editor 6 - Manual (Page 82)

Page 82
Client Side Programming Issues
When using TCP to connect to a remote site, there may be some considerable delay in the connection being
accepted, or the remote site may be down, in which case you can hang CRiSP until the connection request
completes or the connection times out.
You can avoid this problem by OR-ing the IPC_NON_BLOCKING flag into the IPC_TCP connection type. In
this case, the ipc_create() function will return immediately and you can register a notification callback to tell
you when the connection has completed. If you use the IPC_NON_BLOCKING parameter, you should delay
reading or writing data down the connection until you are sure the connection has been established properly.
Server Side Programming Issues
For a server, the issues are similar. A server can handle multiple incoming connections at the same time. To
achieve this you can register a connection notification. When an incoming connection is received, you then
issue the ipc_accept() function. This creates a brand new connection and leaves the original connection
handle ready for subsequent connection attempts.
Examples
The following example code illustrates a client making a request and sending a single message - all in a
blocking manner. The macro will not terminate until the (possibly long) connection has completed:
void
client_example1()
{
int ipc_id;
if ((ipc_id = ipc_create(IPC_TCP, "remotehost:1234")) < 0) {
message("Connection failed, errno=%d", errno);
return;
}
ipc_write(ipc_id, "Hello\n");
ipc_close(ipc_id);
}
The following example illustrates the same code as above, but without blocking on the
ipc_create():
IPC_TRIGGER_WRITE
void
client_example_non_block()
{ int ipc_id;
if ((ipc_id = ipc_create(IPC_TCP | IPC_NON_BLOCKING,
"remotehost:1234")) < 0) {
message("Connection failed, errno=%d", errno);
return;
}
message("Awaiting connection completion...");
ipc_register(ipc_id, IPC_TRIGGER_WRITE,
"connection_callback");
}
void
connection_callback(int ipc_id)
{