socket服务器的问题。

Magic_LP

在学习的过程遇到这样一个问题。创建一个socket服务器

问题一：没显式的设置成非阻塞模式，那默认的应该是阻塞模式吧？
问题二：accept以后，说明就是有客户连进来了，这个时候TCP的三次握手也完成了吧？
问题三：按照流程，既然accept成功，那就应该是期待客户输入数据了，调用readn(使用UNP里提供的循环读)，为什么对于不同的客户端会有不同的结果。有的是能马上就直接返回，而有的又会阻塞(貌似会一直阻塞到客户端超时)？我理解是这样的，对于readn，假设都是要求读100B的数据，但实际客户发过来的数据只有80B，那按照UNP中写的readn，要么读够100个字节，要么读到结束就退出。是不是对于有的客户端可以读到结束标志，而对于有的客户端读不到结束符，才会出现以上说的哪种情况？如果是，我要怎样避免这样的阻塞？（现实有个需求就是，我不知道客户会发多大的数据过来，但我可以保证客户发的数据不会超过一个阀值，每次按这个最大值去调用readn的时候，有的客户端就会出现阻塞的情况，而有的又不会，是不是跟套接口设置为阻塞有关啊？如果是，那为什么有的客户端又不会超时？纠结我好久了）。

大大们，快快现身吧~~

Magic_LP

看来大牛们都休息了，那我也睡觉去了，希望明早起来可以看到答案~

lanying_wzw

加个固定长度的头，表示后续发的字节数

teng0210

报文要有规则,
比如http
有Content-Length 还有chunk的方式 来指明报文长度

hellioncu

1、是
2、是
3、上面的都说了

Magic_LP

谢谢大家的回复，难道就只有加报文头这一个解决办法吗？我也想过这个办法，但是作为服务器的程序，有很多渠道接进来，在我们不能都要求每个客户端程序都加报文长度的情况下，就没有解决办法吗？

peidright

回复 6# Magic_LP


    设置为非阻塞，不能解决问题么。。

hellioncu

谢谢大家的回复，难道就只有加报文头这一个解决办法吗？我也想过这个办法，但是作为服务器的程序，有很多渠 ...
Magic_LP 发表于 2010-07-17 12:20

    不知道你的服务端具体的功能是啥。
如果没有表示长度的东西，怎么来区分收到的报文，要知道TCP是一个数据流