最近烦人的事情很多,所以博客一直被落下了。这样不好,希望可以敦促自己不要懒惰。前些日子接下了一个撂摊子的项目,这个项目中大量的使用udp socket进行多软件多硬件的来回通讯过程,但说实话通信量不是特别大。但是经常遇到各种各样奇怪的现象。在解决这些问题过程中,也算加强了一些基础知识的学习,在此也顺便记录下解决步骤,以便下次项目中使用。该项目中软件部分有A、B两个软件。其中A和B都有各自的发送
转载 2023-08-24 14:18:00
366阅读
测试系统在Linux上的性能发现率极为严重,发210000条数据,达110000之巨,率超过50%。同等情形下Windows上测试,仅几条数据。形势严峻,必须解决。考虑可能是因为协议栈Buffer太低所致,于是先看看默认情况: sysctl -a |grep net.core 发现 net.core.rmem_max = 131071 net.core.rmem_defa
转载 2023-12-12 17:10:34
236阅读
  最近在做一个项目,在这之前,做了个验证程序. 发现客户端连续发来1000个1024字节的,服务器端出现了现象. 纠其原因,是服务端在还未完全处理掉数据,客户端已经数据发送完毕且关闭了. 我用过sleep(10),暂时解决这个问题,但是这不是根本解决办法,如果数据量大而多,网络情况不太好的话,还是有可能丢失.你试着用阻塞模式吧..
转载 2023-12-21 12:50:05
129阅读
UDP及无序问题 最近在做一个项目,在这之前,做了个验证程序. 发现客户端连续发来1000个1024字节的,服务器端出现了现象. 纠其原因,是服务端在还未完全处理掉数据,客户端已经数据发送完毕且关闭了. 有没有成熟的解决方案来解决这个问题. 我用过sleep(1),暂时解决这个问题,但是这不是根本解决办法,如果数据量大而多,网络情况不太好的话,还
转载 2024-08-16 20:23:54
83阅读
关于udp传输的不可靠性,用过这个的人都知道会。具体细节可能就不清楚了,经过我的理解和总结,有以下两点:1)udp的大小可以达到64k,但实际上mtu大小只有1k多,如果直接发一个超过mtu大小的,就会在协议层被分片,这样的问题是,如果只要有一个分片在传输中出错了即校验不正确(这是较容易发生的),整个传输的udp就被丢弃。注意是整个而不是单个分片。这就是为什么发送udp通常也是1k多大
一、主要原因1、接收端处理时间过长导致:调用recv方法接收端收到数据后,处理数据花了一些时间,处理完后再次调用recv方法,在这二次调用间隔里,发过来的可能丢失。对于这种情况可以修改接收端,将接收后存入一个缓冲区,然后迅速返回继续recv。2、发送的巨大:虽然send方法会帮你做大包切割成小包发送的事情,但太大也不行。例如超过50K的一个udp,不切割直接通过send
转载 2023-07-28 16:17:06
519阅读
摘要本文记录通过数据报套接字来检测UDP数据的延迟和的思路和简单的代码实现。思路UDP协议及用户数据报协议在传输层提供了无连接、不可靠的传输服务,端到端的延迟以及率是反应当前网络环境好坏的重要评价标准。Ping检测延迟的方式是:发送端发送一个ICMP包给接收端,接收端接收到ICMP之后向发送端回应一个,发送端可以计算出往返时间(RTT),本文通过套接字使用类似于Ping的思路来计算R
转载 2023-10-05 09:09:13
299阅读
Linux UDP严重问题的解决 测试系统在Linux上的性能发现率极为严重,发210000条数据,达110000之巨,率超过50%。同等情形下Windows上测试,仅几条数据。形势严峻,必须解决。考虑可能是因为协议栈Buffer太低所致,于是先看看默认情况:   sysctl -a |grep net.core   发现 &nb
转载 精选 2012-06-15 14:01:32
7781阅读
# 如何实现Android udp ## 概述 在Android开发中,UDP(User Datagram Protocol)是一种无连接的传输协议,它可以实现高效的数据传输,但也容易出现的情况。对于刚入行的小白开发者而言,了解如何处理UDP是非常重要的。本文将向你介绍如何在Android应用中处理UDP问题。 ## 流程步骤 以下是处理Android UDP的流程步骤:
原创 2024-06-08 06:19:36
49阅读
之前一直没考虑清楚为何接收到UDP数据的问题,当意识到这造成很大问题时便狂查资料,有以下结论: 1.发送方发送的数据太快,导致UDP输入队列溢出(系统会丢掉一些),在应用程序看来是即是。解决方法:1.想办法提高应用程序对UDP的处理速度。2.提高UDP输入队列缓冲区大小,可通过setsockopt的SO_RCVBUF来进行设置,但是这里的设置还受限于系统的设置,在linux系统下可以
转载 2023-08-30 17:11:30
275阅读
今天UDP组播问题,可把我害惨了,130个,接收端总是只接受到121个,稳定9个,我一直以为是代码逻辑问题,但是通过130个单步调试发现,单步调试就是不。后来去复习了一下UDP。豁然开朗,UDP发送过快就是会导致的,难怪我单步调试就不。心累。 UDP原因一、主要原因1、接收端处理时间过长导致:调用recv方法接收端收到数据后,处理数据花了一些时间,处理
转载 2023-10-05 14:06:46
673阅读
刚开始对netty udp不太熟的朋友可能会遇到这么一个问题,在使用netty udp发送数据的时候,如果你的比较大,或者超过2048字节的时候,经常会接收不全或者包了。比如发送一个4096字节的DatagramPacket到服务器,你会发现只接收到2048或者更少的字节。是什么原因呢?下面说一下个人的见解:udp理论上支持最大发送64K的,那为什么netty udp不能发送大于2048字
什么会导致udp呢,我这里列举了如下几点原因: 1.调用recv方法接收端收到数据后,处理数据花了一些时间,处理完后再次调用recv方法,在这二次调用间隔里,发过来的可能丢失。对于这种情况可以修改接收端,将接收后存入一个缓冲区,然后迅速返回继续recv。 2.发送的太大而。虽然send方法会帮你做大包切割成小包发送的事情,但太大也不行。例如超过30K的一个udp,不切割直接通过
转载 2023-08-04 13:18:48
202阅读
        今天收到故障电话,说交部分电脑上网极度缓慢,严重。  迅速telnet上远程交换机,show  pro  cpu查看到很担忧的一幕, cpu使用率达87%,  连命令输入有时都会卡,  情况比较可能是广播风暴、病毒。  查看拓扑,在show mac-
原创 2010-08-18 23:52:18
3003阅读
1评论
   今天收到报障,说网络严重。   查看拓扑,拓扑中显示的很简单,一台65为核心,下接一台Cisco3524(这台sw下面的终端严重)冗余连接----类似这样 口====口 ,拓扑是这么显示的,show cdp nei也是显示只有一台互联设备。所以第一步先看下上联端口, show interface gi0/1  显示正常 (这个为转发口),
原创 2010-08-12 17:53:17
1580阅读
1评论
快中午了,开发那边反应121.14.11.38在操作机上ping严重,我在我机器上ping一下,果然如此,之后我在操作机上traceroute 121.14.11.38, traceroute 121.14.11.38 traceroute to 121.14.11.38 (121.14.11.38), 30 hops max, 38 byte packets   1&nbs
原创 2012-03-18 14:58:52
8694阅读
1点赞
2评论
网络严重         在网络的故障率方面,网络严重的情况也会经常发生,当网络严重时,会对网络造成以下后果:         第一:视频会议说话断断续续       &n
原创 2012-03-23 15:26:42
1088阅读
1点赞
2评论
1.概念(1)bps是指比特率bps是线路单位,表示bit(比特)/second(秒)。在计算机网络或者是网络运营商中,一般,宽带速率的单位用bps(或b/s)表示;bps表示比特每秒即表示每秒钟传输多少位信息。(2)pps是指网络吞吐率pps是包转发率单位,表示/秒,交换机每秒可以转发多少百万个数据(Mpps),即交换机能同时转发的数据的数量。(3)BpsBps是用户在网上下载时显示的速
# Android UDP广播与现象 在Android开发中,UDP(用户数据报协议)是一种常见的网络传输协议,尤其适用于需要低延迟传输数据的场景,比如在线游戏、实时视频传输等。然而,由于UDP是无连接的协议,相比TCP,它更容易发生现象。本文将探讨Android UDP广播的基本实现,并分析问题。 ## 什么是UDP广播? UDP广播是指将数据报文发送到子网中的所有主机。与单播
原创 2024-10-26 04:33:45
88阅读
# Android UDP 问题解析及解决方案 UDP(用户数据报协议)因其简单性和低延迟特性,常用于实时应用,如视频流、在线游戏和语音通话。然而,UDP协议没有流控制和重传机制,这也导致了数据的丢失。本文将探讨在Android开发中如何处理UDP问题,提供代码示例,并分析如何优化UDP传输。 ## UDP的特性 UDP是一种无连接的协议,这意味着在发送数据前不需要建立连接。虽然这
原创 2024-08-09 14:52:38
113阅读
  • 1
  • 2
  • 3
  • 4
  • 5