就是字符串比较长，一次发完担心出问题。
查了一下，网上都是 传输/接收 文件的形式来传输大数据，如果字符串就是在内存中呢？接收的时候也是保存在内存里。
------解决思路----------------------
举出具体的例子。你所谓的“传输字符串”如果没有业务意义，也就没有必要存在。
------解决思路----------------------
算了，我给你举个例子吧。我猜你也一下子想不出什么完整的描述。
比如说你传送一个视频，比如说原来是
var cmd = new Media{ bytes= data, object_id="123133213"};那么你现在可以传
var cmd = new MediaPart{ bytes= data, object_id="123133213", position=77844};由于它们都有object_id，因此知道目标是什么。所不同的，后者在传送之前，你可能需要首先声明一下 123133213 号对象的完整的长度，这样服务器端每当接收到（多个） MediaPart 的时候就可以判断是否已经接收完全了，一旦接收到完整数据，才开始下一步处理。------解决思路----------------------
缓存一个Byte 512 之类的 然后循环一读取,读完存储完为止.发的那边也是 存一个Byte 512 一直发,发完为止??
------解决思路----------------------
那么你这个问题整个就误导别人了。
客户端就算是1024字节的缓冲区，也可以接收4000000个字节的消息数据啊！最基本的，任何stream操作几乎都是循环的，例如
var buffer = new byte[4096];这就能接受4000000000000个字节的消息。
var mm = new MemoryStream();
var len = 0;
while ((len = stream.Read(buffer, 0, buffer.Length)) > 0)
mm.Write(buffer, 0, len);
这其实是应在上学时学过的基本Stream操作知识。
------解决思路----------------------
http://download.csdn.net/detail/mengweishengshuyang/2430241
这个例子可以参考下
我看过觉得写的还是蛮不错的
------解决思路----------------------
个人见解，欢迎大家一起纠正：
第一networkstream.BeginRead(so.buffer, 0, so.buffer.Length, ReadCallback, so);你给个so这个数组让他读，有好几种情况会发生：1超过数组长度（超过长度，在下个BeginRead里再给你），2不到数组长度，所以你真正收到的buffer长度是int length = myNetworkStream.EndRead(ar); 3.还有一种情况你收到的数组长度可能是零，那可能是双方中断连接了这个错误最好throw一下
第二，一收到数据就反序列化有这么几点不好，tcp发送可能传一半断一半再连一半，如客户机发送 aaa bbb两个实例，收到时可能aa abb这两条buffer或者其它的情况.所以不管什么情况先收到了，再在收到以后通过一个中间的处理类去处理你的buffer,看他是否把一个实例收完整了，没完整的等下次补完了再处理。比如存在一个helper类里的MemoryStream里处理
第三根据tcp传速的这么多问题，所以最好再给每个传送的实例加上头跟尾巴，比如头部写上开始符号+实例包长度 尾巴部纯一个结束符（开始结束符不可与序例化实例的buffer有批评）
第四虽然很朋友建议多线程尽量少用同步，比如看情况你在Listener没有参照microsoft放上ManualResetEvent同步。个人感觉在listener异步监听时有必要放个同步，万一两个或多个线程同处理完多个异步监听，是不是会出来有多个listener.BeginAcceptTcpClient。这样当下线几个连接进入是会是什么情况，我还没测试过，下次测了汇报
纯个人实际操作中的一点点见解，
------解决思路----------------------
你这次调试不通过可能就是序列化时包不完整吧，catch (SerializationException e)一下试试