DMNETSEND(3dm) DMNETSEND(3dm)
dmNetSend, dmNetRecv - send and receive DMbuffers
#include <dmedia/dmnet.h>
DMstatus dmNetSend(DMNetConnection connection, DMbuffer dmbuf);
DMstatus dmNetRecv(DMNetConnection connection, DMbuffer *dmbuf);
dmNetSend sends the specified DMbuffer over the open data connection
specified by DMnetconnection.
dmNetRecv returns a filled DMbuffer from the open data connection
specified by DMnetconnection. The DMbuffer is allocated from the
DMbufferpool which had been previous registered with the call to
dmNetRegisterPool or is pre-allocated and passed into dmNetRecv, after a
call to dmNetRegisterBuffer .
If the caller does not set the MSC associated with the DMbuffer ,
dmNetSend will provide a monotonically increasing value. To avoid
possible confusion, callers should either always set an MSC value, or
never set one.
dmNetSend and dmNetRecv will cooperate in an attempt to make the UST
value at the receiving end of a network connection equivalent to the UST
value that was set at the sending end. This is accomplished by converting
the UST to an equivalent "wall clock" value (via
dmGetUSTCurrentTimePair). This wall clock value is sent to the receiving
end, which converts it back to an equivalent local UST value. For this
to be effective, the system clocks on the two machines must be
synchronized by some external mechanism, such as xntpd or timed.
If the sender sets the UST value to zero, dmNetSend and dmNetRecv will
leave the value undisturbed. This is a convenient way for the sender to
indicate that the receiver that the clock value is not to be trusted.
Depending on the underlying transport protocol, dmNetSend and dmNetRecv
may or may not block (see the NOTE below). They return DM_SUCCESS or
DM_FAILURE.
dmNetSend and dmNetRecv fail if one or more of the following are true:
EINVAL connection is not a valid connection descriptor.
ESHUTDOWN the peer has closed the underlying network connection.
Page 1
DMNETSEND(3dm) DMNETSEND(3dm)
In addition, dmNetSend can fail as follows:
EBUSY insufficient internal resources to send the buffer (only
when the underlying transport mechanism is using a DMS
fifo; usually indicates that the receiver is not reading
quickly enough).
EPIPE receiver died in the middle of a write system call (dmNet
catches SIGPIPE and reports errno as EPIPE).
dmNetRecv can fail as follows:
EBUSY no data is available to be read (only when the underlying
transport mechanism returns filled DMbuffers via a DMS
fifo; currently only DMNET_LOCAL).
ENOMEM no DMbuffer could be allocated for the incoming data.
ENODATA end of file reached - no more data available.
ERANGE the buffer allocated from the pool is too small to hold
the received data.
Depending on the underlying transport mechanism, the exact semantics of
dmNetSend and dmNetRecv will vary. Some transports never block, instead
returning EBUSY when there are insufficient resources or no waiting data.
Others block if only some of the data has arrived on the network
connection, or if the outgoing network connection is too full to deliver
all of the data into the kernel. Applications that are concerned about
timely execution of these routines should use select and dmNetDataFd to
determine the likelihood that data is ready. It should go without saying
that they must also carefully check the return and error values. Error
values are may be obtained through dmGetError
Most applications will want to call these routines in a separate thread.
dmBufferAllocate(3dm), dmGetUSTCurrentTimePair(3dm), dmNetDataFd(3dm),
dmNetRegisterPool(3dm), dmNetRegisterBuffer(3dm), select(2), xntpd(1L),
timed(1M)
DMNETSEND(3dm) DMNETSEND(3dm)
dmNetSend, dmNetRecv - send and receive DMbuffers
#include <dmedia/dmnet.h>
DMstatus dmNetSend(DMNetConnection connection, DMbuffer dmbuf);
DMstatus dmNetRecv(DMNetConnection connection, DMbuffer *dmbuf);
dmNetSend sends the specified DMbuffer over the open data connection
specified by DMnetconnection.
dmNetRecv returns a filled DMbuffer from the open data connection
specified by DMnetconnection. The DMbuffer is allocated from the
DMbufferpool which had been previous registered with the call to
dmNetRegisterPool or is pre-allocated and passed into dmNetRecv, after a
call to dmNetRegisterBuffer .
If the caller does not set the MSC associated with the DMbuffer ,
dmNetSend will provide a monotonically increasing value. To avoid
possible confusion, callers should either always set an MSC value, or
never set one.
dmNetSend and dmNetRecv will cooperate in an attempt to make the UST
value at the receiving end of a network connection equivalent to the UST
value that was set at the sending end. This is accomplished by converting
the UST to an equivalent "wall clock" value (via
dmGetUSTCurrentTimePair). This wall clock value is sent to the receiving
end, which converts it back to an equivalent local UST value. For this
to be effective, the system clocks on the two machines must be
synchronized by some external mechanism, such as xntpd or timed.
If the sender sets the UST value to zero, dmNetSend and dmNetRecv will
leave the value undisturbed. This is a convenient way for the sender to
indicate that the receiver that the clock value is not to be trusted.
Depending on the underlying transport protocol, dmNetSend and dmNetRecv
may or may not block (see the NOTE below). They return DM_SUCCESS or
DM_FAILURE.
dmNetSend and dmNetRecv fail if one or more of the following are true:
EINVAL connection is not a valid connection descriptor.
ESHUTDOWN the peer has closed the underlying network connection.
Page 1
DMNETSEND(3dm) DMNETSEND(3dm)
In addition, dmNetSend can fail as follows:
EBUSY insufficient internal resources to send the buffer (only
when the underlying transport mechanism is using a DMS
fifo; usually indicates that the receiver is not reading
quickly enough).
EPIPE receiver died in the middle of a write system call (dmNet
catches SIGPIPE and reports errno as EPIPE).
dmNetRecv can fail as follows:
EBUSY no data is available to be read (only when the underlying
transport mechanism returns filled DMbuffers via a DMS
fifo; currently only DMNET_LOCAL).
ENOMEM no DMbuffer could be allocated for the incoming data.
ENODATA end of file reached - no more data available.
ERANGE the buffer allocated from the pool is too small to hold
the received data.
Depending on the underlying transport mechanism, the exact semantics of
dmNetSend and dmNetRecv will vary. Some transports never block, instead
returning EBUSY when there are insufficient resources or no waiting data.
Others block if only some of the data has arrived on the network
connection, or if the outgoing network connection is too full to deliver
all of the data into the kernel. Applications that are concerned about
timely execution of these routines should use select and dmNetDataFd to
determine the likelihood that data is ready. It should go without saying
that they must also carefully check the return and error values. Error
values are may be obtained through dmGetError
Most applications will want to call these routines in a separate thread.
dmBufferAllocate(3dm), dmGetUSTCurrentTimePair(3dm), dmNetDataFd(3dm),
dmNetRegisterPool(3dm), dmNetRegisterBuffer(3dm), select(2), xntpd(1L),
timed(1M)
PPPPaaaaggggeeee 2222 [ Back ]
|
