Flash的Socket只支持TCP（10.x之后所谓的UDP支持只是在流数据的实时p2p上才有用），所以目前Comoro的Base也只支持TCP连接，当然改成UDP并不很困难，只是需要注意更多的数据完整性检查。
由于Flash动画是基于帧的，所以Flash的socket也是受帧影响的，as中所有事件也是随帧触发的。比如一个30fps的swf，它每1/30秒检测一遍事件，也就是ENTER_FRAME是最底层的event，一般的键盘持续响应、动画都是基于它来检测的。Socket中的事件也是一样，这就意为着，如果再一个1/30秒内，socket收到1条以上的消息，事件却只触发了一次，于是缓冲内的东西就被会被一次取出，几条消息就粘连到一起了。其它应用平台也会有粘连情况，只是不像flash这么严重，因为它的检测间隔太大，远比什么“cpu时钟级”、“微秒级”高得多。
另外，TCP的连接检测也是非常没谱的。当一个连接断开后，TCP栈可能在2小时的时候才会有消息产生，所以几乎所有的网络程序都会有“心跳”，包括聊天工具、网络游戏等。心跳就是定时向对方发送一条特殊的消息，由对方反馈，如果一段时间内收不到心跳消息或者没有反馈，就可以认为这个连接“死掉”了。
另一个比较严重的问题就是数据丢失及顺序错乱。有人认为TCP是不会丢的，其实丢失不是因为TCP本身，是在路上由于无线信号干扰、路由器拥堵等被丢弃了。反馈消息也许也是由中继路由器返回的，不是真正的送到了接收方。这在网络环境不好的时候经常发生。TCP协议本身有重发机制，假设服务器第一次调用send/write, 发送了表示登录成功的第一条业务消息, 然后再发送表示通知客户端进入游戏大厅的业务消息. 那么, 无论网络如何失败, TCP保证, 如果消息真能到达, 那么必定是第一条先于第二条到达。
基于以上原因，一个稳定的连接，需要一个完整的消息顺序机制，需要有分割已粘连消息的能力。消息的包头至少要包含顺序号和长度才能满足这类需求。
