t**********1
发帖数: 550 | 1 现在的协议设计，RespID是int32_t，32位整数。
我认为用来验证次序应该够了(加上时间戳)。
大叫说说需要增加到int64_t么？估计好虫短期不会来了。欢迎大家提意见。 |
|
g****u
发帖数: 252 | 2 其实你用48位的reqID和respID，就可以档住近一年每秒10M请求。
消息大小不变。其实都到这地步了，消息再大点也无所谓。
我觉得不用换。我的客户端预先分配所有的req/resp空间。
撑不了几秒钟的test。长时间大规模的蹂躏还要等goodbug。 |
|
g****u
发帖数: 252 | 3 有了这个全局唯一递增的respID，就可以验证老魏的算法是否有错。
赌局要求不能出现现在没票，过了一会儿又有票的情况。如果某
m-n区段的请求在respID=100被据了，任何respID>100都不能再卖
完全包含在m-n之间的票。
这是我的理解。 |
|
c*******n
发帖数: 1214 | 4 If it is due to anxiety, then some SSRIs (prozac, etc) may help, in addition
with Lorazepam at night. Sometimes some patients may need low dose
antipsychotics (0.5 mg to 2 mg respidal) to control the symptoms. |
|
g****u
发帖数: 252 | 5 请解释下，是不是说我一个socket开两个线程，一个往里写NetReq结构，
一个往外读NetResp结构？seat表示什么？如果输入_train = -1，
seat又应该是什么？为什么reqID是64位，而respID是32位？
< |
|
g****u
发帖数: 252 | 6 再问你个问题，你协议中的respID是针对每个connection递增的，还是
全局递增的？一般来说都是针对每个connection递增的，但是因为你
核心是单线程，可以做到全局不重复递增。请解释下。 |
|
t**********1
发帖数: 550 | 7 RespID是全局递增保证唯一的。
这个可以做到跟核心无关，IO都是单线程的，可以在这里保证唯一。
即使多线程，locked increment也就一条指令。 |
|
|
g****u
发帖数: 252 | 9 不一样。老魏已经解释了。不然resp中不需要同时返回respID和reqID |
|
n****j
发帖数: 1708 | 10 没仔细看老魏代码，不太明白为啥要这个 respID，是要给后端 DB 发的吗？ |
|
n****j
发帖数: 1708 | 11 我看足够了，时间戳也没啥必要。4G 的 log 要验证，其中最多 150M 是 success，也
要有个稍微像样点的算法，蛮干且一会呢。 |
|
t**********1
发帖数: 550 | 12 那就32位吧。
我家两台烂server，中间还间隔两个desktop switch。单连接勉强上1M/s。
我好好测试一下再把代码放出来吧。 |
|
g****u
发帖数: 252 | 13 我已经在ebay上订了两块10gb的网卡了，还等着玩RDMA呢。 |
|
|
|
t**********1
发帖数: 550 | 16 没试过，用过这么多年10G，连switch长啥样都不知道，都是别人弄好的。
我家还有两块solarflare，我也不会连。 |
|
g****u
发帖数: 252 | 17 你这话被赵策看到，够他说好几年的。几十块钱的东西，要搞不定就算了。 |
|
n*****t
发帖数: 22014 | 18 架构没问题，争议在性能，一个请求多票和多个请求单票是等价的，如果这些请求连续
执行。古德吧认为每秒不会超过 10 万票，这个节点会成为新瓶颈。
不要求这个是为了验证结果方便，因此还额外增加了 respID。约定多票算多个请求，
古德吧对自己没信心，怕老魏批处理反而提升性能了。 |
|
|
|
