关于UDP通信,同一个端口收发的问题

[lwy7758]

请问下, 我想实现客户端和服务端的UDP通信, 但是需要Client端4000发送数据到Server端的8000, 并且4000再收取Server端发回的数据, 这个能实现吗? 可以的话怎么写呢? 我用UDPClient不能在一个端口上操作.

[gxingmin]

UDP同一个端口就可以同时负责发和收啊，怎么不能在同一个端口上操作？ 参考这里的代码

[於黾]

为什么要这样设计? 你就不敢两台电脑都用4000发,用8000收?

[liuxiaoboQQ]

当然没问题啊。Client4000>Server8000 然后 Server8000>Client4000 这样很正常啊。我理解错了没

[lwy7758]

引用 2 楼 Z65443344 的回复:

为什么要这样设计? 你就不敢两台电脑都用4000发,用8000收?

不是我这样设计啊, 是TX这样设计的. 我只是模仿

[於黾]

接收端不要直接绑定端口4000,设置成IPAddress.Any就行了

[於黾]

IPAddress.Any,0

[以专业开发人员为伍]

引用 楼主 lwy7758 的回复:

请问下, 我想实现客户端和服务端的UDP通信, 但是需要Client端4000发送数据到Server端的8000, 并且4000再收取Server端发回的数据, 这个能实现吗? 可以的话怎么写呢? 我用UDPClient不能在一个端口上操作.

发送端口不需要固定什么4000，随机由UdpClient 选择一个发送端口就行。发送之后，立刻读取数据。而服务器端从端口8000接收到请求，应该立刻向客户端（接收消息时就会获得RemoteIpEndPoint客户端对外端口）发送返回（比如说200毫秒以内），这样就能让发送消息的客户端收到返回结果。 要注意的是，Udp通讯时你必须较快地让服务器发送返回消息，否则中间的路由器可能已经中断了处理、不再允许外部主动联系内部了。 这里有必要纠正几个很容易误导人的概念： 1. 客户端不需要固定端口，客户端发送消息时应该由UdpClient自动选择可用的端口。 2. 不要说什么“服务器向4000端口发送消息”，那是瞎扯，是因为只在小办公室里几台电脑规模的小网络下搞测试造成的。真正应用网络环境下，大部分客户端都在NAT路由器以后，就算是客户端绑定了4000固定端口，经过1个或者多个NAT路由器处理，那么服务器端针对的客户端端口也不大可能是4000，此时服务器端可能应该向“最终路由器IP、端口号62102”发送返回消息，才能到达内部局域网IP、4000号端口这里来。 3. 服务器不可能向NAT内部的客户端主动发起消息，必须等客户端发送消息，然后赶紧发送返回值。因为NAT路由器只会为Udp消息的这种回发规则维护一个较短时间，在这个较短时间上由外部发来的消息才能被路由器正确转发给内部。

[以专业开发人员为伍]

比如说，你的客户端IP是192.168.0.100，端口号是4000，使用Udp方式向服务器 202.100.200.123:8000 发送了一个消息，那么经过路由器——不管中间有几个路由器——最终是以 211.149.101.21:62018 发送出去的，那么这时候难道有人告诉你说“你的服务器要向 192.168.0.100:4000 发送 Udp 返回值啊！”么？这就是误导你了。 最起码的Udp服务器端编程，也是向你的服务器端 Receive 语句所返回的 RemoteIpEndPoint（也就是211.149.101.21:62018 ） 发送返回值，这样才能最终到达局域网内 192.168.0.100:4000。而这个 RemoteIpEndPoint 的值每一次可能都是变动的，因为路由器会采用不同的端口发送不同的消息。 然后，对于客户端，你根本没有必要绑定 4000端口。你的 new UdpClient() 得到的这个对象，可以发送消息，紧接着Receive，就能收到返回值。发送端口号（不管是4000还是40000）应该由人家自动选择，你只定一个端口号没有多少好处。 当然这里是指一般的Udp通讯的概念。如果你有什么特别的“设计”，或许你确实需要固定内部端口号。但是那也是在你确实知道基本的概念之后的事情。

[以专业开发人员为伍]

引用 4 楼 lwy7758 的回复:

[quote=引用 2 楼 Z65443344 的回复:] 为什么要这样设计? 你就不敢两台电脑都用4000发,用8000收?

不是我这样设计啊, 是TX这样设计的. 我只是模仿[/quote] 请你把 TX 源程序贴出来！

[江南小鱼]

引用 7 楼 sp1234 的回复:

[quote=引用 楼主 lwy7758 的回复:] 请问下, 我想实现客户端和服务端的UDP通信, 但是需要Client端4000发送数据到Server端的8000, 并且4000再收取Server端发回的数据, 这个能实现吗? 可以的话怎么写呢? 我用UDPClient不能在一个端口上操作.

发送端口不需要固定什么4000，随机由UdpClient 选择一个发送端口就行。发送之后，立刻读取数据。而服务器端从端口8000接收到请求，应该立刻向客户端（接收消息时就会获得RemoteIpEndPoint客户端对外端口）发送返回（比如说200毫秒以内），这样就能让发送消息的客户端收到返回结果。 要注意的是，Udp通讯时你必须较快地让服务器发送返回消息，否则中间的路由器可能已经中断了处理、不再允许外部主动联系内部了。 这里有必要纠正几个很容易误导人的概念： 1. 客户端不需要固定端口，客户端发送消息时应该由UdpClient自动选择可用的端口。 2. 不要说什么“服务器向4000端口发送消息”，那是瞎扯，是因为只在小办公室里几台电脑规模的小网络下搞测试造成的。真正应用网络环境下，大部分客户端都在NAT路由器以后，就算是客户端绑定了4000固定端口，经过1个或者多个NAT路由器处理，那么服务器端针对的客户端端口也不大可能是4000，此时服务器端可能应该向“最终路由器IP、端口号62102”发送返回消息，才能到达内部局域网IP、4000号端口这里来。 3. 服务器不可能向NAT内部的客户端主动发起消息，必须等客户端发送消息，然后赶紧发送返回值。因为NAT路由器只会为Udp消息的这种回发规则维护一个较短时间，在这个较短时间上由外部发来的消息才能被路由器正确转发给内部。[/quote] sp1234，高人 mark

[lwy7758]

引用 3 楼 pengwu666 的回复:

当然没问题啊。Client4000>Server8000 然后 Server8000>Client4000 这样很正常啊。我理解错了没

主要是不知道怎么实现, 我试了用4000发送, 但在监听4000的时候, 就要报错, 说端口已占用.

[lwy7758]

引用 7 楼 sp1234 的回复:

[quote=引用 楼主 lwy7758 的回复:] 请问下, 我想实现客户端和服务端的UDP通信, 但是需要Client端4000发送数据到Server端的8000, 并且4000再收取Server端发回的数据, 这个能实现吗? 可以的话怎么写呢? 我用UDPClient不能在一个端口上操作.

发送端口不需要固定什么4000，随机由UdpClient 选择一个发送端口就行。发送之后，立刻读取数据。而服务器端从端口8000。[/quote] 谢谢你这么详细解释!

[乄z詪情绪化]

请问 由于不知道返回的数据包的端口号 怎么监听呢

[last_fxlt]

…………说的那么清楚了，只能原端口快速返回，才能穿过内网到达客户端，换个端口发不进来，路由直接给伱扔了

[爱与奇迹的物语]

引用 8 楼 sp1234 的回复:

比如说，你的客户端IP是192.168.0.100，端口号是4000，使用Udp方式向服务器 202.100.200.123:8000 发送了一个消息，那么经过路由器——不管中间有几个路由器——最终是以 211.149.101.21:62018 发送出去的，那么这时候难道有人告诉你说“你的服务器要向 192.168.0.100:4000 发送 Udp 返回值啊！”么？这就是误导你了。 最起码的Udp服务器端编程，也是向你的服务器端 Receive 语句所返回的 RemoteIpEndPoint（也就是211.149.101.21:62018 ） 发送返回值，这样才能最终到达局域网内 192.168.0.100:4000。而这个 RemoteIpEndPoint 的值每一次可能都是变动的，因为路由器会采用不同的端口发送不同的消息。 然后，对于客户端，你根本没有必要绑定 4000端口。你的 new UdpClient() 得到的这个对象，可以发送消息，紧接着Receive，就能收到返回值。发送端口号（不管是4000还是40000）应该由人家自动选择，你只定一个端口号没有多少好处。 当然这里是指一般的Udp通讯的概念。如果你有什么特别的“设计”，或许你确实需要固定内部端口号。但是那也是在你确实知道基本的概念之后的事情。

我有个问题哈，只能在较快时间内返回的话，UDP 是如何传输超大文件的？超大文件的传输时间是很长的，而且现在有很多做这个的程序是UDP 的。

[流星泪哥]

引用 8 楼 sp1234 的回复:

比如说，你的客户端IP是192.168.0.100，端口号是4000，使用Udp方式向服务器 202.100.200.123:8000 发送了一个消息，那么经过路由器——不管中间有几个路由器——最终是以 211.149.101.21:62018 发送出去的，那么这时候难道有人告诉你说“你的服务器要向 192.168.0.100:4000 发送 Udp 返回值啊！”么？这就是误导你了。 最起码的Udp服务器端编程，也是向你的服务器端 Receive 语句所返回的 RemoteIpEndPoint（也就是211.149.101.21:62018 ） 发送返回值，这样才能最终到达局域网内 192.168.0.100:4000。而这个 RemoteIpEndPoint 的值每一次可能都是变动的，因为路由器会采用不同的端口发送不同的消息。 然后，对于客户端，你根本没有必要绑定 4000端口。你的 new UdpClient() 得到的这个对象，可以发送消息，紧接着Receive，就能收到返回值。发送端口号（不管是4000还是40000）应该由人家自动选择，你只定一个端口号没有多少好处。 当然这里是指一般的Udp通讯的概念。如果你有什么特别的“设计”，或许你确实需要固定内部端口号。但是那也是在你确实知道基本的概念之后的事情。

能不能给推荐一本C#网络编程方面的书，网络编程新手

[michealblank]

其实很多网关是有端口要求的，本地客户端A IP地址和端口是192.168.2.2：4000，需要发给服务器B的端口是114.100.25.8:8080，经过网关后A的IP和端口变为221.14.24.5:16784。如果服务器想主动给客户端A发送消息，需要向221.14.24.5:16784发送消息，但是很多网关是要求相同端口返回的，也就是说服务器必须要绑定8080端口，所以服务器就出现了这种情况，不仅要在8080端口上监听UDP数据，同时也要绑定8080端口向外发送消息。客户端A也一样，必须要在4000端口上发送消息，同时也要监听4000端口接收数据。