erlang socket总结

1、tcp 函数对流操作，而不是包

2、gen_tcp:recv(Socket, Length, TimeOut)  Length 只在 Socket是raw模式时起作用，socket一般都不用raw模式吧，所以Length这个参数一般无意义 

3、gen_tcp:listen(Port,Opt),Opt 中的packet 字段 表示每次收逻辑包读取流数据的模式，比如{packet,4} 表示流的前4个字节存储客户端发的逻辑包的长度Length（不是tcp包的长度，一个逻辑包可能包拆分成多个tcp包），send的时候erlang会自动计算下逻辑数据的长度，然后把长度存在4个字节加到在逻辑数据的最前面，erlang在recv数据时首先在流里取4个字节读出本次逻辑包的长度，这个时候会阻塞在recv函数这里直到流里的数据长度等级逻辑包长度。raw {packet,0}表示有多少拿多少，没有救不拿，recv会马上返回流里的所有数据，其他情况会等待拿到length后才返回，{packet, http} 。。这个稍后再说

4，一个Socket只能被一个进程控制，只有这个控制进程可以读这个Socket的流，但所有进程都可以向这个socket流里写数据，控制进程死了，Socket自动关闭，Socket关闭了控制进程会受到一个类似{Socket，close}的消息。

5，游戏服务器网络模型 每个玩家对应3个进程 一个Socket的读进程A（Socket的控制进程），一个写Socket的进程B,处理玩家逻辑的进程C；Socket的参数是 {active,false},A进程刚出生的时候会处理登陆校验和注册的逻辑，不通过直接死掉，通过登录哦了一辈子阻塞在gen_tcp:recv上，读到到数据发给进程C然后在进入recv，不断重复这两部直到有一天A要死了，A不会自杀，A和C是link的，当C死的时候A突然就死了没有任何预兆，在A的生命周期它可能会收到两种特别的包，etimeout和 close，收到这两种包的时候都会通知C，这两种情况A都没救了，不同的是etimeout的时候如果及时有新的A替代它与C相连C就不用死，，A还会做一件无聊的事，数它收到包的频率，频率高就会问C需不需要死。。。；C进程处理游戏的逻辑；B进程负责发包，它出生的意义在于合并包。