1<html>
2
3<head>
4<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
5<LINK rel="stylesheet" type="text/css" href="../CSS/revolution.css">
6
7<title>MPSendAsync</title>
8</head>
9
10<body>
11<h1>MPSendAsync</h1>
12
13<h2>C Specification</h2>
14<p>
15<dl>
16  <dd><pre><code>#include &lt;revolution/mp.h&gt;</code></pre>
17  </dd>
18  <dd><pre><code>s32 MPSendAsync (
19        const void* <i><b>data</b></i>,
20        u32 <i><b>length</b></i>,
21        u32 <i><b>aidBits</b></i>,
22        u32 <i><b>port</b></i>,
23        u32* <i><b>restBits</b></i>,
24        <a href="MPCallback.html">MPCallback</a> <i><b>cb</b></i>,
25        void* <i><b>userData</b></i> );</code></pre>
26  </dd>
27</dl>
28</p>
29
30<h2>Arguments</h2>
31<p>
32<table border="1">
33  <tr>
34<td valign="top" width="120" bgcolor="#ffffe8"><code><strong><em>data</em></strong></code></td>
35<td width="520">Pointer to the data to be sent</td>
36  </tr>
37  <tr>
38<td valign="top" width="120" bgcolor="#ffffe8"><code><strong><em>length</em></strong></code></td>
39<td width="520">Length of the data to be sent</td>
40  </tr>
41  <tr>
42<td valign="top" width="120" bgcolor="#ffffe8"><code><strong><em>aidBits</em></strong></code></td>
43<td width="520">AID list of the send destinations</td>
44  </tr>
45  <tr>
46<td valign="top" width="120" bgcolor="#ffffe8"><code><strong><em>port</em></strong></code></td>
47<td width="520">Port number sending the data</td>
48  </tr>
49  <tr>
50<td valign="top" width="120" bgcolor="#ffffe8"><code><strong><em>restBits</em></strong></code></td>
51<td width="520">List of AIDs that need resends</td>
52  </tr>
53  <tr>
54<td valign="top" width="120" bgcolor="#ffffe8"><code><strong><em>cb</em></strong></code></td>
55<td width="520">Callback function to be called when an asynchronous function completes</td>
56  </tr>
57  <tr>
58<td valign="top" width="120" bgcolor="#ffffe8"><code><strong><em>userData</em></strong></code></td>
59<td width="520">Pointer value that is passed to the callback function and can be used at will in the application</td>
60  </tr>
61</table>
62</p>
63
64<h2>Return Values</h2>
65
66<P>Returns the processing results or a negative number if processing fails.</P>
67
68<h2>Description</h2>
69
70<p>Sends data asynchronously. Once an attempt is made to send the send data, the result is stored in <CODE>*restBits</CODE> and a call is made to <CODE>cb</CODE>. Note that the value is not actually set in <code>*restBits</code> until <CODE>cb</CODE> is called.<br>Even when a send fails, the result from cb is <CODE>MP_RESULT_OK</CODE>. You can tell that data was actually sent to all the destinations if <CODE>restBits</CODE> is 0.</p>
71<p>The <CODE>restBits</CODE> bit is sometimes set even if sending succeeded. Conversely, if communications fail, the <CODE>restBits</CODE> 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.</p>
72<p>The value of <CODE>restBits</CODE> indicates other parties that must be resent. Specifically, of the parties specified by <CODE>aidBits</CODE>, the corresponding bits of <CODE>restBits</CODE> 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.<br>When a connection notification arrives, set the <CODE>aidBits</CODE> 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 <CODE>aidBits</CODE>. Then, when sending data, decide whether to resend by looking at <CODE>restBits</CODE>. 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 <CODE>restBits</CODE> whenever a child is completely unconnected as a special case of the above.</p>
73<p>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, <code>MP_RESULT_BUSY</code> 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.</p>
74<p>The pointer to the user data passed to the callback function is passed to the <CODE>userData</CODE> 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.</p>
75<p>The <CODE>port</CODE> number can be set to numbers 5 through 8 for raw communications and numbers 12 through 15 for sequential communications by the application.</p>
76<p><font color="red">For sequential communications, the properties are only guaranteed for connections of up to eight children. </font>Connections of more than eight children are not guaranteed to have the sequential communications' advantage that successfully sent data always reaches its target.</p>
77
78<h2>See Also</h2>
79<p>
80<code><a href="./MPSend.html">MPSend()</a></code>, <code><a href="./MPError.html">MPError</a></code>, <code><a href="./MPCallback.html">MPCallback</a></code>, <code><a href="./MPCallbackInfo.html">MPCallbackInfo</a></code>
81</p>
82
83<h2>Revision History</h2>
84
85<p>
862007/11/28 Made revisions in conjunction with the addition of the MPCallback type to the function reference.<br>2007/10/03 Changed the explanation about sequential communications. Made revisions in line with change to final argument.<br>2007/01/29 Added a description of <CODE>restBits</CODE>.<br>2006/08/22 Added a description of <CODE>restBits</CODE>.<br>2006/06/29 Initial version.
87</p>
88
89<hr><p>CONFIDENTIAL</p></body>
90</html>