1.属性
常用属性见表7.4。
表7.4
2.回调属性
回调属性见表7.5。
表7.5
3.接口
(1)send
说明：
mixed Connection：：send(mixed$data[，$raw=false])
向客户端发送数据。
参数：
data
要发送的数据，如果在初始化Worker类时指定了协议，则会自动调用协议的encode方法，完成协议打包工作后发送给客户端。
$raw
是否发送原始数据，即不调用协议的encode方法，默认是false，即自动调用协议的encode方法。
返回值：
true表示数据已经成功写入到该连接的操作系统层的Socket发送缓冲区。
null表示数据已经写入到该连接的应用层发送缓冲区，等待向系统层Socket发送缓冲区写入。
false表示发送失败，失败原因可能是客户端连接已经关闭，或者该连接的应用层发送缓冲区已满。
注意：
send返回true，仅仅代表数据已经成功写入到该连接的操作系统Socket发送缓冲区，并不意味着数据已经成功的发送给对端Socket接收缓冲区，更不意味着对端应用程序已经从本地Socket接收缓冲区读取了数据。不过即便如此，只要send不返回false并且网络没有断开，而且客户端接收正常，数据基本上可以看作100%能发到对方的。
由于Socket发送缓冲区的数据是由操作系统异步发送给对端的，操作系统并没有给应用层提供相应确认机制，所以应用层无法得知Socket发送缓冲区的数据何时开始发送，应用层更无法得知Socket发送缓冲区的数据是否发送成功。基于以上原因WorkerMan无法直接提消息确认接口。
如果业务需要保证每个消息客户端都收到，可以在业务上增加一种确认机制。确认机制可能根据业务不同而不同，即使同样的业务确认机制也可以有多种方法。
例如聊天系统可以用这样的确认机制。把每条消息都存入数据库，每条消息都有一个是否已读字段。客户端每收到一条消息向服务端发送一个确认包，服务端将对应消息置为已读。当客户端连接到服务端时（一般是用户登录或者断线重连），查询数据库是否有未读的消息，有的话发给客户端，同样客户端收到消息后通知服务端已读。这样可以保证每个消息对方都能收到。当然开发者也可以用自己的确认逻辑。
范例：(www.xing528.com)
(2)getRemoteIp
说明：
string Connection：：getRemoteIp()
获得该连接的客户端ip。
参数：
无参数
范例：
(3)getRemotePort
说明：
int Connection：：getRemotePort()
获得该连接的客户端端口。
参数：
无参数
范例：
(4)close
说明：
void Connection：：close(mixed$data='')
安全的关闭连接。
调用close会等待发送缓冲区的数据发送完毕后才关闭连接，并触发连接的onClose回调。
参数：
$data
可选参数，要发送的数据（如果有指定协议，则会自动调用协议的encode方法打包$data数据），当数据发送完毕后关闭连接，随后会触发onClose回调。
范例：
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
