Location:
es_prot.h
Link against:
MSocketNotify
Supported from 5.0
Abstract base class used by a
CServProviderBase
-derived object through its iSocket
member to notify the socket server that various events have occurred. The class
provides several up-call member functions.
All up-calls on the MSocketNotify
should be made in
the context of the socket server’s thread — i.e. the thread which
called NewSAPL()
on the protocol.
Defined in MSocketNotify
:
CanClose()
, CanSend()
, ConnectComplete()
, DisConnect()
, EDelete
, EDetach
, EErrorAllOperations
, EErrorClose
, EErrorConnect
, EErrorFatal
, EErrorIoctl
, EErrorRecv
, EErrorSend
, Error()
, IoctlComplete()
, NewData()
, TDelete
, TOperationBitmasks
virtual void NewData(TUint aCount)=0;
Indicates that new data is available on a service access point.
For a stream-oriented protocol aCount
should be a byte count; for
datagram-oriented sockets aCount
should be a datagram
count.
Note that aCount
is the amount of new data, not
the total amount of data waiting to be read.
|
virtual void ConnectComplete()=0;
virtual void ConnectComplete(const TDesC8& aConnectData)=0;
virtual void ConnectComplete(CServProviderBase& aSSP)=0;
virtual void ConnectComplete(CServProviderBase& aSSP,
const TDesC8 &aConnectData)=0;
Indicates that a connection attempt has completed successfully. There are four versions of this up-call: the first two are for active opens and the second two are for passive opens.
Both active and passive versions support a variant carrying user connection data for protocols which support it.
The last two versions of ConnectComplete()
, which are
for passive opens, carry a new SSP (socket service provider, or SAP) for the
newly created socket. A new socket will then be linked up to the SSP and data
transfer can take place. The original socket stays listening.
Notes:
A connection-less protocol should never call the
ConnectComplete()
up-calls.
A protocol should keep a count of sockets which have called
ConnectComplete()
but have not had Start()
called.
Sockets in this state have their Error()
and
NewData()
calls deferred until Start()
is
called.
|
virtual void CanClose(TDelete aDelete=EDelete)=0;
virtual void CanClose(const TDesC8& aDisconnectData, TDelete aDelete=EDelete)=0;
Indicates that the SAP has finished closing down. This up-call is the
response to a Shutdown()
. A connection-oriented protocol should
call CanClose()
when it has terminated communications with the
remote host. Protocols can call CanClose()
from within their
Shutdown()
code. After CanClose()
has been called, a
SAP may be deleted by the socket server.
Notes:
The protocol must not access the CServProviderBase
object after calling CanClose()
.
|
virtual void Error(TInt anError, TUint anOperationMask=EErrorAllOperations)=0;
Tells the socket server that an error state has arisen within the
protocol. It should not be used to report programmatic errors, either in the
protocol itself or the socket server (a panic should be used in these cases).
When Error()
is called on a connection-oriented socket, the socket
is moved into a dead state which denies user access to it.
|
virtual void DisConnect()=0;
virtual void DisConnect(TDes8& aConnectData)=0;
Indicates that the other end of a connection has disconnected. This is
analogous to CanClose()
, but in this case the other end initiated
it.
Once the client has called Shutdown()
it is illegal to call
DisConnect()
. Instead, CanClose
() or
Error(KErrDisConnected)
should be called.
|
virtual void IoctlComplete(TDesC8* aBuf)=0;
Indicates that the currently pending Ioctl has completed.
The parameter aBuf
is protocol defined — in fact it is
defined by the specific Ioctl.
|
TOperationBitmasks
Error codes.
|