#include <revolution/mp.h>
s32 MPSendAsync (
const void* data,
u32 length,
u32 aidBits,
u32 port,
u32* restBits,
MPCallback cb,
void* userData );
data |
Pointer to the data to be sent |
length |
Length of the data to be sent |
aidBits |
AID list of the send destinations |
port |
Port number sending the data |
restBits |
List of AIDs that need resends |
cb |
Callback function to be called when an asynchronous function completes |
userData |
Pointer value that is passed to the callback function and can be used at will in the application |
Returns the processing results or a negative number if processing fails.
Sends data asynchronously. Once an attempt is made to send the send data, the result is stored in *restBits and a call is made to cb. Note that the value is not actually set in *restBits until cb is called.
Even when a send fails, the result from cb is MP_RESULT_OK. You can tell that data was actually sent to all the destinations if restBits is 0.
The restBits bit is sometimes set even if sending succeeded. Conversely, if communications fail, the restBits bit is supposed to be set for certain, but if more than eight children are connected to the Wii there is no guarantee for this either. When a number of children are connected, you will need at times to confirm the arrival of data at the application level.
The value of restBits indicates other parties that must be resent. Specifically, of the parties specified by aidBits, the corresponding bits of restBits are not set for those parties that are not connected or that were disconnected during communications. The reason for this is that resending to a disconnected party is pointless. Be sure to check whether other parties have been disconnected using a separate disconnect notification. Under MP communications, there is no guarantee that data sent to a party immediately before a disconnect actually reaches that party.
When a connection notification arrives, set the aidBits to be sent to as part of the registration process conducted by the application, and when a disconnect notification arrives, perform removal processing and clear the bit in aidBits. Then, when sending data, decide whether to resend by looking at restBits. In the case of disconnected children, perform processing after reconnection (if necessary) under the assumption that data sent immediately before a disconnect may not have arrived. This is the basic design concept behind MP communications. Note that zero is always returned in restBits whenever a child is completely unconnected as a special case of the above.
In the previous implementation, the work region for the asynchronous function was passed as an argument, but this is no longer necessary. Instead, there is now a limit on the number of asynchronous functions that can be called at the same time. If this limit is exceeded, MP_RESULT_BUSY is given as the return value. In the present implementation, a total of 32 functions can be called at the same time, including both synchronous and asynchronous functions, from different MP libraries.
The pointer to the user data passed to the callback function is passed to the userData argument. The pointer value specified here is passed to the callback function without being evaluated inside the library, so it is all right to specify an illegal value.
The port number can be set to numbers 5 through 8 for raw communications and numbers 12 through 15 for sequential communications by the application.
For sequential communications, the properties are only guaranteed for connections of up to eight children. Connections of more than eight children are not guaranteed to have the sequential communications' advantage that successfully sent data always reaches its target.
MPSend(), MPError, MPCallback, MPCallbackInfo
2007/11/28 Made revisions in conjunction with the addition of the MPCallback type to the function reference.
2007/10/03 Changed the explanation about sequential communications. Made revisions in line with change to final argument.
2007/01/29 Added a description of restBits.
2006/08/22 Added a description of restBits.
2006/06/29 Initial version.
CONFIDENTIAL