小编fab*_*zi0的帖子

根据node.js断言库文档:

该模块供Node.js内部使用,但可以通过require('assert')在应用程序代码中使用.但是,assert不是测试框架,并不打算用作通用断言库.

我在看Chai作为替代断言库(没有BDD API,只有断言API),最后我看到断言功能非常相似.

为什么Chai的断言库是一个更好的断言库？它完成了除node.js之外的所有工作(除了在可用的断言方面更加丰富,但这只是语法糖涂层).即使是简单的事情,例如执行的assert总数也不可用.

我错过了什么吗？

在我寻求免费警告应用程序时,我已经开始使用-Werror来告诉gcc将所有警告视为错误.

这确实非常有用,因为有时我在大型构建输出中错过了一两个(严重)警告.不幸的是,我的项目使用的sqlite3包含许多警告,如sqlite网站中所述,无法消除(他们不想删除).

我想知道是否有一种方法可以使用一些#pragma我可以放在sqlite3.c文件中告诉gcc停止将警告视为仅对该文件的错误.

我尝试过:

#pragma GCC diagnostic ignored "-Werror"

没有成功我也试图逐个列出导​​致问题的警告:

#pragma GCC diagnostic ignored "-Wextra"
#pragma GCC diagnostic ignored "-Wfloat-equal"
#pragma GCC diagnostic ignored "-Wundef"
...

...遗憾的是,有些警告无法完全关闭(即初始化会从指针目标类型中丢弃限定符).

有什么想法/建议？

我试图了解接收器窗口如何影响高延迟连接的吞吐量.

我在两台相距很远的机器上有一对简单的客户端 - 服务器应用程序,两者之间的连接是250毫秒延迟RTT.我使用Windows(XP,7)和Linux(Ubuntu 10.x)运行此测试,结果相同,所以为了简单起见,我们假设:客户端接收数据:WinXP Pro Server发送数据:Win7 Pro再次,延迟是250毫秒RTT.

我在不更改客户端上的接收器缓冲区大小的情况下运行TCP测试(默认为8Kb),我在线上看到(使用Wireshark):

• 客户端向服务器发送ACKS,TCP包包含RWIN = 65k
• 服务器发送数据并报告RWIN = 65k

查看跟踪,我看到3-4个数据包(有效载荷为1460字节)的突发,紧接着是从客户端机器发送到服务器的ACK,然后没有任何约250毫秒然后来自服务器的新数据包突发给客户.

因此,总而言之,服务器似乎甚至在填满接收者窗口之前就不会发送新数据.

为了做更多的测试,这次我还运行了相同的测试,在客户端机器上更改了接收器的缓冲区大小(在Windows上,更改接收器的缓冲区大小最终会影响机器公布的RWIN).我希望在阻止ACK之前看到大量的数据包突发...并且至少有更高的吞吐量.

在这种情况下,我将recv缓冲区大小设置为100,000,000.从客户端到服务器的数据包现在有一个RWIN = 99,999,744(好吧,那很好),但不幸的是从服务器发送到客户端的数据模式仍然是相同的:短暂的突发,然后是漫长的等待.为了确认我在线上看到的内容,我还测量了从服务器向客户端发送大量数据的时间.我没有看到使用大型RWIN或使用默认值的任何更改.

任何人都可以帮助我理解为什么更改RWIN并不会真正影响吞吐量？

很少有注意事项: - 服务器使用8Kb块的write()尽可能快地发送数据 - 正如我之前所说,我也看到了使用Linux的类似效果.更改接收器缓冲区大小会影响节点使用的RWIN,但吞吐量保持不变. - 我分析了数百个数据包之后的跟踪,给TCP足够的时间启动机制放大CWIN大小.

正如所建议的那样,我在这里添加了一条线迹的小快照

No.     Time        Source                Destination           Protocol Length Info
     21 2.005080    CCC.CCC.CCC.CCC       sss.sss.sss.sss       TCP      60     57353 > 21500 [ACK] Seq=1 Ack=11681 Win=99999744 Len=0
     22 2.005109    sss.sss.sss.sss       CCC.CCC.CCC.CCC       TCP      1514   21500 > 57353 [ACK] Seq=19305 Ack=1 Win=65536 Len=1460
     23 2.005116    sss.sss.sss.sss       CCC.CCC.CCC.CCC       TCP      1514   21500 > 57353 [ACK] Seq=20765 Ack=1 Win=65536 Len=1460
     24 …