关于C#完成端口和socket客户端问题并用问题

[一条大灰狼]

1. 根据项目需求，写一个TCP客户端（完成端口）每秒接收20M数据（千兆网），接收数据不丢包
2. 最近又要改成发送指令和接收数据各一个客户端（即发送指令客户端：192.168.199.122 4999；接收数据客户端：192.168.199.122 5000），现在接收数据严重丢包，请问哪位大神知道这是什么原因？

[以专业开发人员为伍]

假设有1千个客户端，从几百公里外通过复杂的许多层路由器连到一个服务器上，那么一个客户端发消息，另一个（或者几个）客户端收到服务器实时推送，这对于 TCP 来说也是举手之劳，轻松编程，没任何问题。看不懂 lz 所写的到底是什么联网方式、什么程序设计。

[以专业开发人员为伍]

对于客户端来说，它本身就是随机端口的，什么叫做“服务器和客户端port得对应”？实在是匪夷所思。

[weixin_43818962]

不错不错

[一条大灰狼]

引用 17 楼 以专业开发人员为伍的回复:

对于客户端来说，它本身就是随机端口的，什么叫做“服务器和客户端port得对应”？实在是匪夷所思。

如果服务端为192.168.199.122 5000监听，客户端不应该也得是192.168.199.122 5000进行链接吗？如果客户端端口号为4999，能连上服务端吗？

[以专业开发人员为伍]

引用 18 楼 qq_37750663 的回复:

[quote=引用 17 楼 以专业开发人员为伍的回复:]对于客户端来说，它本身就是随机端口的，什么叫做“服务器和客户端port得对应”？实在是匪夷所思。

如果服务端为192.168.199.122 5000监听，客户端不应该也得是192.168.199.122 5000进行链接吗？如果客户端端口号为4999，能连上服务端吗？[/quote] 按照你这个说法，“发送指令客户端：192.168.199.122 4999；接收数据客户端：192.168.199.122 5000”实际上是说服务器端的程序设计，而根本不是说客户端的设计？ 这里“客户端、服务器端”两个词儿显然在随便乱用。就好像把 csdn 网站服务器说成是浏览器端。

[還是]

抓包吧，看它发过来的数据是否是完整的（分别抓包对比两个程序的就可以了）。感觉它那边的问题可能性比较大，你这边两个端口与第一种方案不是一样的么。第一种没问题，第二种有问题，可能是它那边处理多客户连接出问题了。 不过为啥要写两个程序，一个程序也没问题吧！

[還是]

引用 19 楼 以专业开发人员为伍 的回复:

[quote=引用 18 楼 qq_37750663 的回复:] [quote=引用 17 楼 以专业开发人员为伍的回复:]对于客户端来说，它本身就是随机端口的，什么叫做“服务器和客户端port得对应”？实在是匪夷所思。

如果服务端为192.168.199.122 5000监听，客户端不应该也得是192.168.199.122 5000进行链接吗？如果客户端端口号为4999，能连上服务端吗？[/quote] 按照你这个说法，“发送指令客户端：192.168.199.122 4999；接收数据客户端：192.168.199.122 5000”实际上是说服务器端的程序设计，而根本不是说客户端的设计？ 这里“客户端、服务器端”两个词儿显然在随便乱用。就好像把 csdn 网站服务器说成是浏览器端。[/quote] 你可以简单理解，发数据的是服务端，收数据的是客户端。数据是采集卡采集的数据，不是一般指令数据。

[wanghui0380]

唉，乱了。

换成计算机语言看吧

bind -------绑定监听的是server
conect--------做连接的是client--client可以使用任意未握手的tcp 套接字进行连接服务端动作

[還是]

引用 2 楼 以专业开发人员为伍 的回复:

客户端程序端口随机，怎么会固定端口？你写的是什么“客户端”概念呢？

客户端也可以指定端口，虽然没必然，但指定也没问题。关键是accept/connect

[一条大灰狼]

就是一个程序，只不过多加了一个TCP，一个负责发送指令，一个负责接受数据，这样的话接收得数据就是纯数据。不掺杂指令回传值！

[一条大灰狼]

引用 14 楼 wanghui0380的回复:

如果说下位机支持多机连接，并且下位机是数据推送，那么都可以不用修改啥
把你的程序复制两份（一份去掉采集和分发，一份去掉上位机指令执行），然后告诉后面的人，要执行指令请连A，要采集的请连B

如果下位机支持多机，但下位机是不支持数据推送，需要你轮询查询
还是上面的策略复制两份（份去掉采集和分发，一份去掉上位机指令执行，然后告诉后面的人，要执行指令请连A，要采集的请连B。同时加上A发送采集指令（使用rpc也好，传统tcp也罢，甚至是ipc，管道等进程间通讯）给B，让他启动B的轮询拉数据并转发过程

-----------------------------
如果下位机不支持多机（比如那是一个串口，虽然串口我们也能用手段把他分成一对多虚拟口，这手段是万不得已采用），那么你只能使用一个代理程序，这时候你可以把数据操作快速中转出去，把解析和分发过程延迟给另外的服务。

比如下位机回馈数据原封不动用进程间通讯手段丢到另外进程去，然后解析别轮询发送了，直接丢一份到MQ里去，然后需要数据的自己去mq里取。

我想问一下哈，如果一个网口，两个TCP通讯，有竞争吗？

[還是]

引用 25 楼 qq_37750663 的回复:

[quote=引用 14 楼 wanghui0380的回复:]如果说下位机支持多机连接，并且下位机是数据推送，那么都可以不用修改啥 把你的程序复制两份（一份去掉采集和分发，一份去掉上位机指令执行），然后告诉后面的人，要执行指令请连A，要采集的请连B 如果下位机支持多机，但下位机是不支持数据推送，需要你轮询查询 还是上面的策略复制两份（份去掉采集和分发，一份去掉上位机指令执行，然后告诉后面的人，要执行指令请连A，要采集的请连B。同时加上A发送采集指令（使用rpc也好，传统tcp也罢，甚至是ipc，管道等进程间通讯）给B，让他启动B的轮询拉数据并转发过程 ----------------------------- 如果下位机不支持多机（比如那是一个串口，虽然串口我们也能用手段把他分成一对多虚拟口，这手段是万不得已采用），那么你只能使用一个代理程序，这时候你可以把数据操作快速中转出去，把解析和分发过程延迟给另外的服务。 比如下位机回馈数据原封不动用进程间通讯手段丢到另外进程去，然后解析别轮询发送了，直接丢一份到MQ里去，然后需要数据的自己去mq里取。

我想问一下哈，如果一个网口，两个TCP通讯，有竞争吗？[/quote] 没有，IP+端口不一致，accept连接时生成的句柄可以拿过来直接读写。

[阿飞不会飞丶]

学习了

[sp1234_maJia]

编写客户端功能代码，根本不 bind，不要纠结什么端口号问题。系统会为了保证通讯，而随机选择一个可用的端口号。 编写服务器端功能代码，需要 bind 端口号。系统根本不可能支持对同一个端口号同时多个 bind。

[Csdn技术大神]

看那个程序出了问题随便试一试

[以专业开发人员为伍]

引用 23 楼 還是 的回复:

客户端也可以指定端口，虽然没必然，但指定也没问题。关键是accept/connect

当然是“可以”多余绑定端口号。重点在于了解原理，而“明知概念有误解还硬要找理由坚持”的理解往往意味着、后边就会演变成“不由自主地”去饱尝各种恶果而自己不愿意消减冗余。

[以专业开发人员为伍]

引用 24 楼 qq_37750663 的回复:

就是一个程序，只不过多加了一个TCP，一个负责发送指令，一个负责接受数据，这样的话接收得数据就是纯数据。不掺杂指令回传值！

一个进程当然可以又 bind 去监听某个服务端口，同时又使用纯客户端的方式来访问其它服务器。但是此时所谓的“发送指令”的socket（或者 tcpclient）就是使用标准的客户端方式，它并不 bind 什么端口，端口是由系统随机选择的号，怎么可能 bind一个端口号？ 另外，所谓“不掺杂回传值”的意思我觉得这个也不是很合理的解释。我们在 tcp 开发中确实见过许多初学者不懂异步道理，比如说按照指令顺序 1、2、3、4、5 发送消息，那么按照顺序 5、1、2、4、3 的顺序收到了对方的返回结果，这种基本的道理就是异步的基本的道理，也是基本的技术。如果为了“避开”基本的技术而去诡异地堆砌别的什么设计，说到底，还是没有基本技术、不愿意实现最基本的功能。

[以专业开发人员为伍]

另外，就算是说你的进程又当服务器又当客户端，也就是“对等网络”架构方式，那么你的整个网络上各个系统也应该是对应的设计实现。假设你不是一位内比较高级的网络架构设计好了之后才采取对等网络技术实现，而是为了回避必须懂得的技术而乱改通讯架构，这很可能要可以地去写一大堆冗余代码、一大堆bug。

[以专业开发人员为伍]

引用 25 楼 qq_37750663 的回复:

我想问一下哈，如果一个网口，两个TCP通讯，有竞争吗？

一个服务器系统可以 bind 监听 100 个端口也没有关系，然后不同的服务端口用不同的命令解析处理来服务。这只是一个自己发布“协议”的问题，也就是想让客户端“以为”不同端口由不同进程监听——实际上还是一个程序监听。但是其实这没有什么实际意义，因为一个进程即使有10万个服务 api 功能，发布一个服务端口就够了，消息信令本身能区别到底访问的是哪一个服务。而且随着软件的扩展更版，服务会不断增加。所以其实服务器监听2个以上的端口，更多地可能是为了方便发布、方便客户端随便“凭爱好任选端口”，而没有什么技术作用。 另外，任何进程都可以作为客户端来访问其它服务，服务器程序也是如此。此时（服务器中作为）客户端的代码直接就使用标准的客户端方式来访问对方，根本用不着先 bind 一个端口，而是由系统自动分配动态端口，根本不存在纠结什么端口的事情。

[liusa1997]

引用 5 楼 qq_37750663 的回复:

[quote=引用 2 楼 以专业开发人员为伍的回复:]客户端程序端口随机，怎么会固定端口？你写的是什么“客户端”概念呢？

服务器和客户端port不得对应吗？大哥！[/quote]
谁说的得对应？服务器监听、等待连接；客户端请求连接；服务器接受连接。就OK了。你做广域网当然得子网穿透。局域网就没必要了