ReceiveAsynchronous (Socket function): Difference between revisions

From m204wiki
Jump to navigation Jump to search
mNo edit summary
Line 44: Line 44:


==Usage notes==
==Usage notes==
==Examples==
<ul>
<li>If <var>ReceiveAsynchronous</var> returns a 0 indicating 
that no bytes were returned, it means either of these:
<ul>
<li>No bytes were available at the instant
the method was called or after the timeout time.
<li>No data will ever be returned on the socket, because we a FIN was returned from the other side.
</ul>
 
A returned o is not ambiguous with the <var>Receive</var> and     
<var>ReceiveAndParse</var> methods, because they only return a 0 when a FIN was received.
But if a 0 is returned from <var>ReceiveAsynchronous</var>, you must determine if it is 
caused by a FIN or not: If <var>ReceiveAsynchronous</var> returns a 0 because a FIN was received, and you call it   
(or <var>Receive</var>) again, you will get a request cancellation. So when <var>ReceiveAsynchronous</var>   
returns a 0, call the <var>[[ReceivedFin_(Socket_function)|ReceivedFin]]</var> method to check if a FIN has been received &mdash; unless you "know" the other side will never close the connection nicely (with a FIN) 
and that the only way the connection can be closed is with a reset.                 
</ul>


==See also==
==See also==

Revision as of 21:40, 8 June 2012

Receive zero or more bytes on this socket (Socket class)

[Introduced in Sirius Mods 7.9]


Syntax

%bytesReceived = socket:ReceiveAsynchronous( [Target=] string, - [[MaxBytes=] number], - [[Options=] string], - [Wait= boolean])

Syntax terms

%BytesReceivednumber
socket A variable or an expression that is a reference to a Socket object.
Target This name allowed parameter is a %variable or an IMAGE item that is the target of the receive operation. It is referred to as the "receive target." Since you may request that some bytes from the socket stream be discarded, the length of the string stored in this target may be less than the %BytesReceived value.
MaxBytes This optional, name allowed, parameter is the maximum number of bytes of data to receive, less the length of the separator string. This optional argument defaults to 0, which means limit the received data (less separator) to the declared length of the receive target.

If maxrecvp is 0 and target is a Longstring, the received data is limited to 2,147,483,647 bytes. The MaxBytes argument value must not exceed 2,147,483,647. MaxBytes may have the special value -1 to indicate there is no limit to the number of bytes received.

Options This optional, name allowed, parameter is an option string, which can contain either of the following:
BINARY Regardless of the socket's BINARY or CHAR port parameter, data is not translated when saved in the receive target. The received string can be translated later in the program using the TranIn method.
CHAR Regardless of the socket's BINARY or CHAR parameter, data is translated when saved in the receive target. The translation is specified by the input table defined by the socket's XTAB port parameter.
PRSTOK [AMBIG|]hexstr[|hexstr]... A set of parse tokens that override the current parse tokens on the socket.

Whether it is set on the port definition or by the Set or ReceiveAndParse methods, PRSTOK must not be NONE or ReceiveAndParse will fail.

Wait Boolean value

that indicates whether it should wait the timeout time before returning if MaxBytes bytes weren't immediately available. Note that if Wait=true and the request for MaxBytes times out, the conection is not closed and some number of bytes between 0 and MaxBytes-1 would be returned. If Wait=False, ReceiveAsynchronous will returned immediately with whatever number of input bytes are available.

Usage notes

  • If ReceiveAsynchronous returns a 0 indicating that no bytes were returned, it means either of these:
    • No bytes were available at the instant the method was called or after the timeout time.
    • No data will ever be returned on the socket, because we a FIN was returned from the other side.

    A returned o is not ambiguous with the Receive and ReceiveAndParse methods, because they only return a 0 when a FIN was received. But if a 0 is returned from ReceiveAsynchronous, you must determine if it is caused by a FIN or not: If ReceiveAsynchronous returns a 0 because a FIN was received, and you call it (or Receive) again, you will get a request cancellation. So when ReceiveAsynchronous returns a 0, call the ReceivedFin method to check if a FIN has been received — unless you "know" the other side will never close the connection nicely (with a FIN) and that the only way the connection can be closed is with a reset.

See also