CAPL Functions » TCP/IP API » Technical Details
Socket Handles
Except for the network information functions of the IP API most of the CAPL Socket API functions take a socket handle of typedword as a first parameter.
NoteThis handle parameter is not the underlying WIN32 SOCKET handle and thus of no general use. You should treat this parameter as an opaque handle.
Socket Behavior
All sockets are created as overlapped sockets and are operated in non-blocking mode. All functions, which cannot complete immediately, are performed in an overlapped and asynchronous manner. Upon completion (successful or not) the CAPL program receives a callback provided that it implements the required completion routine.Error Handling
Almost all of the functions have a return value of typelong. The value returned indicates the status of the operation (successful or not) and is – in almost all cases - identical to the return value of the underlying Winsock 2 API. That means that the return value is typically either zero if no error occurs or SOCKET_ERROR (-1) otherwise. To get a specific error code for the last socket operation, use the IpGetLastSocketError function. If an invalid socket handle is passed to a CAPL Socket API function the value WSA_INVALID_PARAMETER (87) is returned.
NoteBecause the entire Winsock 2 API is used in an overlapped, asynchronous manner, functions such as UdpReceiveFrom, TcpReceive and TcpConnect will almost always return the value SOCKET_ERROR. Use the IpGetLastSocketError function to determine whether the operation is just pending or a real error has occurred. Winsock 2 Error Codes