• 2017-09-04

    国内某品牌云主机SSH远程后无法在终端显示远程路径的问题

    Views: 21252 | No Comments

    如果你用 Mac 自带的 Terminal SSH 远程登录远程主机,那边会在 Terminal 的窗口标题栏显示出类似

    user -- user@host:~
    

    这样的信息。这个信息包含远程主机的用户名,主机名,远程路径等等。非常有用。

    但是,国内某品牌的云主机,却无法显示这些信息。经查,原来该品牌使用的 Linux 系统,/etc/bashrc 文件与其它的不同,我怀疑是该公司的工程师私自改的。他们在文件末尾加上了:

    export HISTSIZE=3000
    export HISTTIMEFORMAT="%F %T "
    export PROMPT_COMMAND="history -a"
    unset HISTCONTROL
    

    正是这一行导致了问题:

    export PROMPT_COMMAND="history -a"
    

    删除即可。

    更新:厂商回复

    您好,这个是我们添加的优化
    目的是在用户在bash上敲了每个命令后,能够及时将命令写入到历史记录文件,防止bash异常退出导致命令没有记录下来,实在不满足您的需求,您可以根据自己的需要考虑取舍。

    又一个"为你好"的坏例子。

    Posted by ideawu at 2017-09-04 16:58:52
  • 2017-06-19

    基于 TCP UDP 协议的实时流媒体的实时性分析

    Views: 28393 | 2 Comments

    直播,电话通话,视频聊天都是实时流媒体的范畴。无论使用 TCP 还是 UDP,都会有延时。有个过时的观点是 UDP 更实时,但我不认为是这样。

    实时流媒体的延时主要有几个因素:发送方缓冲,接收方缓冲,网络延时。缓冲包括网络缓冲,录制缓和冲播放缓冲。假设发送方缓冲是 10ms,接收方缓冲都是 50ms,网络延时是 100ms,那么就有至少 160ms 的播放延时。接收方缓冲比发送方多,是为了解决所谓的 jitter,网络延时不均匀导致的播放断续。

    如果使用 UDP,如果丢包,那么接收方的缓冲就从 50ms 变为 40ms,交互延时变小,随着继续丢包变为 0 时,网络延时不旦不均匀就会发生 jitter 了。这时开始缓冲,一共花 50ms,所以信号中断最多 50ms,也即接收方缓冲。

    如果使用 TCP,丢包会导致 TCP 重传,因为网络 rtt 是 200ms,到 50ms 时,接收方的缓冲已经没有数据了,只能等待网络传输,然后再等 150 ms(也即信号中断 150 ms),突然一次收到 110ms 的数据到接收方缓冲中。为了保证低延时,主动丢弃最早的 60ms 数据。使用 TCP,信号中断时时长是 150 ms,也即网络 rtt 减去接收方缓冲。因为 TCP 最坏情况要重传3次,所以是 3*rtt 减去接收方缓冲。

    Continue reading »

    Posted by ideawu at 2017-06-19 20:31:58 Tags: ,
  • 2017-06-19

    SIP INVITE 会话建立过程

    Views: 21568 | No Comments

    运行于 UDP 之上的 SIP,因为 UDP 是不可靠传输的,所以 SIP 协议本身要自己实现可靠传输。对于如何可靠传输,SIP 的 RFC 文档没有要求实现独立的传输层,而是将可靠传输隐含于交互过程本身。如果像 TCP/IP 协议那样分层,特点是清晰。而将可靠传输隐含于交互,则可控程度更高,当然也更复杂。

    所以,RFC 中创造了一些概念,如 Transaction 等等,对于有经验的程序员来说,这完全没必须,反而造成困扰。对于程序员,用几句简单的过程描述就可以解决。如下。

    Client: 定期重复发送 INVITE 直到收到响应。
    Server:收到 INVITE 后,定期重复发送响应,直到收到 ACK。
    Client:收到响应后回复 ACK,认为会话已经建立。这时如果再次收到响应,回复一个 ACK。
    Server:收到 ACK,认为会话已经建立。这时如果再次收到 INVITE 或者 ACK,丢弃。

    Continue reading »

    Posted by ideawu at 19:05:35 Tags: ,
  • 2017-06-18

    自建一个电话呼叫中心要多少钱?

    Views: 24935 | 5 Comments

    我十分看不惯任何行业的潜规则行为。自建一个电话呼叫中心的报价是多少钱?没有人敢公开报价。我明说吧,自建一个电话呼叫中心,只需要3万元左右,而且还能更省钱。

    这个报价是针对小型企业的,也就是广大人民群众。至于大型企业,它们自己去定制,钱不是问题。

    3万元建一个电话呼叫中心,包括什么?包括硬件设备,软件。软件是硬件设备上免费赠送的,不要钱!有了这个呼叫中心,你可以有语音导航功能(也就是按0转人工客服),还有人工客服排队,电话录音。够用了,中小企业没那么多花哨的需求。

    其它的什么狗屁工单,CRM,根本没人用,没这个需求,不会有人愿意付费的。这年头,开发一个工单系统CRM系统根本就是几块钱的事,再说,现在的公司哪个没有自己的CRM工作流?没有人愿意为这些鸡肋功能付费,所以很多厂商逮着一个人就漫天报价,10万,20万,100万!就想着坑到一个是一个。

    Posted by ideawu at 2017-06-18 00:46:22 Tags: ,
  • 2017-06-16

    SIP tag 和 Call-ID 的区别

    Views: 24624 | No Comments

    SIP 的一次通话,可以通过 From, To, Call-ID 三元组来区分。但是,为什么 From 和 To 不用固定的地址,而要在地址后面加上 tag=随机数 呢?

    tag 的目的是为了解决自己给自己打电话的问题(Hairpinning)。如果你自己给自己打电话,那么你应该有两个 Session,但是,如果 From 和 To 是固定的,你就无法区别这两个 Session 哪个是 caller 哪个是 callee。发送 INVITE 时,caller 会在 From 中带有 tag=随机数,而 callee 发送响应时,在 To 后面补充 tag=随机数,不同的随机数分别表示 caller 和 callee。

    所以,RFC 3261 中说:

    The combination of the To tag, From tag, and Call-ID completely defines a peer-to-peer SIP relationship...

    用的是 From tag 和 To tag,而不是用 From 和 To。

    Posted by ideawu at 2017-06-16 19:29:25 Tags: ,
  • 2017-06-16

    SIP报文Via和Contact的区别

    Views: 24287 | No Comments

    Via 是网络层的信息,SIP 报文将通过网络层发往这两个地址。Contact 是业务上的地址。那么问题是,应该发往哪个?

    正确的做法是,请求响应模式中的响应发往 Via。如果解析 DNS 之后能直连 Contact,那么之后的报文(无论是否是请求响应模式)发往 Contact。

    请求如果经过多个代理,每个代理都增加自己的 Via,变成 Via 列表。最终节点回复响应时,带有全部 Via 列表,根据最后一个 Via 获知要发送的目的网络地址。每个代理转发响应时,把最后一个属于自己的 Via 删除,再根据前一个 Via 得到要转发的目的网络地址。

    这样,代理可以做无状态转发请求和响应,其中请求转发依赖路由表,响应转发依赖 Via 列表。

    Posted by ideawu at 18:54:05 Tags: ,
|<<<123456789>>>| 5/124 Pages, 743 Results.