问题背景
公司有一套消息推送系统（简称GCM），由于人事变动接手了其中的客户端部分。看了一下文档，仅通讯协议部分有几页简单的说明，代码呢又多又乱，一时理不出一个头绪。由于消息是从后台推送到端的，所以使用了 tcp 长连接通道来保证消息的及时性，基于 http 的一堆分析工具（如 postman）完全没有用武之地，因此决定写个小工具来模拟 tcp 上的通讯协议，作为深入熟悉代码之前的热身。
问题的解决
一开始想用 c++ 来写这个工具，但是想到 socket 一连串经典的（socket / bind / connect / send / recv…）的繁琐调用我还是算了，之前用 shell 写过几个小工具很舒爽，但那都是借用 curl 命令来处理 http 协议，面对 tcp 协议 curl 肯定是无能为力了，因为命令执行完成后连接也就断开了，无法模拟长连接。那是不是就不能用 shell 写了呢？非也。
连接的建立与断开
我突然想到 shell 本身好像可以支持将 tcp 连接打开为文件：
- exec N <> /dev/tcp/host/port
上面这段脚本就可以在句柄为 N 的文件上打开到 host 且端口为 port 的 tcp 连接了，并且可以进行双向读写。于是赶快在 msys2 中试了一下：
- 1 exec 3<>/dev/tcp/$gcm_host/$gcm_port
- 2 ret=$?
- 3 echo "open tcp $ret"
- 4 if [ $ret != 0 ]; then
- 5 echo "connect to gcmserver failed"
- 6 exit 1
- 7 fi
- 8
- 9 echo "connect with server"
这里脚本直接使用标准输入(0)、输出(1)、错误(2)之后的句柄 3 作为连接句柄，跑了一下，似乎什么也没有发生：
好在 Windows 上有 procexp 工具，可以查看进程创建的所有 tcp 连接：
看起来这个连接确实建立成功了。当然你也可以用 windows 上的 netstat 命令查看：
- C:\Users\yunh>netstat -no
-
- 活动连接
-
- 协议 本地地址 外部地址 状态 PID
- TCP 10.2.56.38:1993 10.100.200.2:10003 ESTABLISHED 10320
- TCP 10.2.56.38:2346 175.27.0.15:80 ESTABLISHED 14808
- TCP 10.2.56.38:2474 121.51.139.161:8080 ESTABLISHED 15092
- TCP 10.2.56.38:3147 10.2.56.13:7680 ESTABLISHED 8816
- TCP 10.2.56.38:3576 47.97.243.182:80 ESTABLISHED 11292
- TCP 10.2.56.38:3602 10.0.24.13:28888 ESTABLISHED 16224
- TCP 10.2.56.38:3720 113.96.233.143:443 ESTABLISHED 15252
- TCP 10.2.56.38:5006 10.2.61.20:7680 ESTABLISHED 8816
- TCP 10.2.56.38:5022 10.2.25.16:7680 ESTABLISHED 8816
- TCP 10.2.56.38:5303 49.232.126.211:443 ESTABLISHED 11292
- TCP 10.2.56.38:6182 10.0.109.249:443 ESTABLISHED 16168
- TCP 10.2.56.38:6183 10.0.109.249:443 ESTABLISHED 16168
- TCP 10.2.56.38:6357 52.11.109.209:443 ESTABLISHED 11292
- TCP 10.2.56.38:6697 40.90.189.152:443 ESTABLISHED 5268
- TCP 10.2.56.38:7065 117.18.237.29:80 CLOSE_WAIT 4724
- TCP 10.2.56.38:7100 220.170.53.122:443 TIME_WAIT 0
- TCP 10.2.56.38:7113 220.181.174.166:443 TIME_WAIT 0
- TCP 10.2.56.38:7117 180.163.150.166:443 ESTABLISHED 11292
- TCP 10.2.56.38:7135 140.143.52.226:443 TIME_WAIT 0
- TCP 10.2.56.38:7141 10.0.24.13:8888 CLOSE_WAIT 16224
- TCP 10.2.56.38:7143 101.201.169.146:443 TIME_WAIT 0
- TCP 10.2.56.38:7144 103.15.99.107:443 TIME_WAIT 0
- TCP 10.2.56.38:7148 203.119.214.115:443 TIME_WAIT 0
- TCP 10.2.56.38:7149 61.151.167.89:443 TIME_WAIT 0
- TCP 10.2.56.38:7150 203.119.169.141:443 TIME_WAIT 0
- TCP 10.2.56.38:7151 203.119.144.59:443 TIME_WAIT 0
- TCP 10.2.56.38:7159 114.55.187.58:443 ESTABLISHED 11292
- TCP 10.2.56.38:7160 42.121.254.191:443 TIME_WAIT 0
- TCP 10.2.56.38:7162 118.178.109.187:443 TIME_WAIT 0
- TCP 10.2.56.38:7165 47.110.223.99:443 TIME_WAIT 0
- TCP 10.2.56.38:7166 116.62.93.118:443 TIME_WAIT 0
- TCP 10.2.56.38:7195 123.150.76.171:80 CLOSE_WAIT 10772
- TCP 10.2.56.38:6974 ################## ESTABLISHED 10984
- TCP 10.2.56.38:7215 192.168.0.9:80 CLOSE_WAIT 4700
- TCP 10.2.56.38:7218 10.2.100.217:7680 SYN_SENT 8816
- TCP 10.2.56.38:7219 192.168.56.1:7680 SYN_SENT 8816
- TCP 10.2.56.38:7680 10.2.102.27:53199 ESTABLISHED 8816
- TCP 10.2.56.38:9763 192.168.23.23:49156 ESTABLISHED 4600
- TCP 10.2.56.38:10267 125.39.132.161:80 ESTABLISHED 10772
- TCP 10.2.56.38:10816 60.205.204.27:80 ESTABLISHED 10872
- TCP 127.0.0.1:443 127.0.0.1:7216 ESTABLISHED 8108
- TCP 127.0.0.1:2002 127.0.0.1:2003 ESTABLISHED 11292
- TCP 127.0.0.1:2003 127.0.0.1:2002 ESTABLISHED 11292
- TCP 127.0.0.1:2013 127.0.0.1:2014 ESTABLISHED 9600
- TCP 127.0.0.1:2014 127.0.0.1:2013 ESTABLISHED 9600
- TCP 127.0.0.1:2015 127.0.0.1:2016 ESTABLISHED 12948
- TCP 127.0.0.1:2016 127.0.0.1:2015 ESTABLISHED 12948
- TCP 127.0.0.1:2040 127.0.0.1:2041 ESTABLISHED 13960
- TCP 127.0.0.1:2041 127.0.0.1:2040 ESTABLISHED 13960
- TCP 127.0.0.1:2109 127.0.0.1:2110 ESTABLISHED 15092
- TCP 127.0.0.1:2110 127.0.0.1:2109 ESTABLISHED 15092
- TCP 127.0.0.1:2349 127.0.0.1:50051 ESTABLISHED 6308
- TCP 127.0.0.1:2566 127.0.0.1:30031 ESTABLISHED 10624
- TCP 127.0.0.1:3032 127.0.0.1:3033 ESTABLISHED 20276
- TCP 127.0.0.1:3033 127.0.0.1:3032 ESTABLISHED 20276
- TCP 127.0.0.1:3517 127.0.0.1:3518 ESTABLISHED 18200
- TCP 127.0.0.1:3518 127.0.0.1:3517 ESTABLISHED 18200
- TCP 127.0.0.1:3768 127.0.0.1:3769 ESTABLISHED 14076
- TCP 127.0.0.1:3769 127.0.0.1:3768 ESTABLISHED 14076
- TCP 127.0.0.1:3854 127.0.0.1:3855 ESTABLISHED 17380
- TCP 127.0.0.1:3855 127.0.0.1:3854 ESTABLISHED 17380
- TCP 127.0.0.1:4895 127.0.0.1:4896 ESTABLISHED 15524
- TCP 127.0.0.1:4896 127.0.0.1:4895 ESTABLISHED 15524
- TCP 127.0.0.1:5320 127.0.0.1:5321 ESTABLISHED 16736
- TCP 127.0.0.1:5321 127.0.0.1:5320 ESTABLISHED 16736
- TCP 127.0.0.1:6688 127.0.0.1:10803 ESTABLISHED 10872
- TCP 127.0.0.1:6688 127.0.0.1:10824 ESTABLISHED 10872
- TCP 127.0.0.1:6688 127.0.0.1:10841 ESTABLISHED 10872
- TCP 127.0.0.1:6688 127.0.0.1:10849 ESTABLISHED 10872
- TCP 127.0.0.1:6689 127.0.0.1:10819 ESTABLISHED 10672
- TCP 127.0.0.1:7187 127.0.0.1:443 TIME_WAIT 0
- TCP 127.0.0.1:7216 127.0.0.1:443 ESTABLISHED 10548
- TCP 127.0.0.1:8419 127.0.0.1:8420 ESTABLISHED 14716
- TCP 127.0.0.1:8420 127.0.0.1:8419 ESTABLISHED 14716
- TCP 127.0.0.1:10803 127.0.0.1:6688 ESTABLISHED 2256
- TCP 127.0.0.1:10819 127.0.0.1:6689 ESTABLISHED 13436
- TCP 127.0.0.1:10824 127.0.0.1:6688 ESTABLISHED 10672
- TCP 127.0.0.1:10841 127.0.0.1:6688 ESTABLISHED 15448
- TCP 127.0.0.1:10849 127.0.0.1:6688 ESTABLISHED 9772
- TCP 127.0.0.1:30031 127.0.0.1:2566 ESTABLISHED 10608
- TCP 127.0.0.1:50051 127.0.0.1:2349 ESTABLISHED 10608
- TCP [::1]:5900 [::1]:5901 ESTABLISHED 10548
- TCP [::1]:5901 [::1]:5900 ESTABLISHED 10548
- TCP [::1]:7188 [::1]:8307 FIN_WAIT_2 8108
- TCP [::1]:7217 [::1]:8307 ESTABLISHED 8108
- TCP [::1]:8307 [::1]:7188 CLOSE_WAIT 8108
- TCP [::1]:8307 [::1]:7217 ESTABLISHED 8108
这里主要是通过过滤进程 ID 来实现快速定位的。连接也可以被主动关闭，这需要使用下面的重定向语法（其实就是关闭普通文件）：
其中 N 就是刚才打开的文件句柄，可以用 > 等效替换 <。在 msys2 中就可以这样验证了：
最后仍然是通过 procexp 工具或 netstat 命令来查看执行结果。另外使用 echo $? 获取 exec 执行结果为 0 似乎并不能确认连接已经建立，因为我对一个错误的 host + port 使用 exec 仍然能得到 0。
机器上下线
连接建立好以后，需要向后台上报本机的一些基本信息，这个协议称为机器上线：
- 1 function send_request_100 ()
- 2 {
- 3 local msg=$(cat protocol/100.gcm)
- 4 # do replace
- 5 msg=$(echo "$msg" | jq --arg guid "$devid" --arg hwid "$hardid" -c '{ version, msgtype, guid: $guid, devinfo: { hwid: $hwid, devid: $guid, os: .devinfo.os, os_version: .devinfo.os_version, sysbit: .devinfo.sysbit, languageid: .devinfo.languageid } }')
- 6 echo $msg >&3
- 7 local ret=$?
- 8 if [ $ret -ne 0 ]; then
- 9 echo "connection break, send failed"
- 10 exit 3
- 11 fi
- 12 }
- 13
- 14 # online myself
- 15 send_request_100
机器上线的过程被封装成了一个函数：send_request_100，这里 100 是机器上线的消息号。其实消息发送就是一句代码的事儿（line 6），这个函数的主要工作是组装 100 协议的内容（line 3-5）。消息都是 json 格式的串，为了降低代码与协议的耦合度，这里把每个协议都放在单独的文件中，例如上面的 “100.gcm” 文件存放的就是机器上线的消息模板：
- {
- "version": "3.1",
- "msgtype": "100",
- "guid": "",
- "devinfo": {
- "hwid": "",
- "devid": "",
- "os": "Windows",
- "os_version": "7",
- "sysbit": "64",
- "languageid": "2052"
- }
- }
从文件中读取到本地变量后，需要做一些填充工作（guid / hwid / devid… 字段），这里使用了 jq 命令的 --arg 选项来传递外部参数并基于它们重新捏合 json 串，这些参数（devid / hardid）又是在脚本启动前就从注册表中读取并传入的。机器上线后才可以进行产品的上下线，而且相应的，当客户端停止时，也要告诉后台机器下线：
- 1 function send_request_101
- 2 {
- 3 local msg=$(cat protocol/101.gcm)
- 4 # do replace
- 5 msg=$(echo "$msg" | jq --arg guid "$devid" -c '{ version, msgtype, guid: $guid }')
- 6 echo $msg >&3
- 7 local ret=$?
- 8 echo "send 101 msg to gcm $ret" >> log.txt
- 9 if [ $ret -ne 0 ]; then
- 10 echo "connection break, send failed"
- 11 exit 3
- 12 fi
- 13
- 14 # no response for 101 message
- 15 echo "offline success! devid=$devid"
- 16 }
- 17
- 18 # -1st offline myself
- 19 send_request_101
这个过程封装在 send_request_101 函数中，这里 101 是机器下线的消息号。同样的，这个消息也有模板文件：
- {
- "version": "3.1",
- "msgtype": "101",
- "guid": ""
- }
相对简单一点。protocol 子目录包含了所有消息协议的模板：
- $ ls -lhrt
- total 7.0K
- -rw-r--r-- 1 yunh 1049089 312 5月 28 2019 102.gcm
- -rw-r--r-- 1 yunh 1049089 102 5月 28 2019 101.gcm
- -rw-r--r-- 1 yunh 1049089 350 5月 28 2019 100.gcm
- -rw-r--r-- 1 yunh 1049089 141 5月 28 2019 412.gcm
- -rw-r--r-- 1 yunh 1049089 166 5月 28 2019 108.gcm
- -rw-r--r-- 1 yunh 1049089 193 5月 28 2019 103.gcm
- -rw-r--r-- 1 yunh 1049089 478 7月 26 2019 custom.gcm
机器下线的其它处理流程和上线差不太多，这里就不赘述了。后面不会对消息内容做详细介绍了，主要是涉及到协议保密的问题。
产品上下线
机器在开机上线，产品在启动时上线，这样当后台有推送内容时，相应的消息就可以推送过来（不会对没上线的产品推送）：
- 1 # $1: app name
- 2 # $2: app version
- 3 # $3: user id
- 4 # $4: device id
- 5 function send_request_102 ()
- 6 {
- 7 local guid=$(echo "$4$1$3" | sha1sum | awk '{ print $1 }')
- 8 local msg=$(cat protocol/102.gcm)
- 9 # do replace
- 10 msg=$(echo "$msg" | jq --arg appname "$1" --arg appver "$2" --arg userid "$3" --arg guid "$guid" -c '{ version, msgtype, guid: $guid, appclientid: $appname, appuserid: $userid, clientinfo: { appversion: $appver, platform: .clientinfo.platform, bits: .clientinfo.bits } }')
- 11 echo $msg >&3
- 12 local ret=$?
- 13 echo "send 102 msg to gcm $ret" >> log.txt
- 14 if [ $ret -ne 0 ]; then
- 15 echo "connection break, send failed"
- 16 exit 3
- 17 fi
- 18 }
- 19
- 20 # online GCMPopBox/GUX/GSUP
- 21 send_request_102 "GCMPopBox" "2.0.0.0" "$hardid" "$devid"
- 22 send_request_102 "GUX" "$version" "$devid" "$devid"
- 23 send_request_102 "GSUP" "$version" "$devid" "$devid"
这个过程封装在 send_request_102 函数中，这里 102 是产品上线的消息号。这个函数接收四个参数，分别是产品标识、产品版本、用户标识和机器标识。在机器上线后，会固定上线三个产品：GCMPopBox、GUX 和 GSUP，都是客户端自带的几个服务产品。当产品关闭时，要向后台发送产品下线消息：
- 1 # $1: app name
- 2 # $2: user id
- 3 # $3: device id
- 4 function send_request_103
- 5 {
- 6 local guid=$(echo "$3$1$2" | sha1sum | awk '{print $1}')
- 7 local msg=$(cat protocol/103.gcm)
- 8 # do replace
- 9 msg=$(echo "$msg" | jq --arg appname "$1" --arg userid "$2" --arg guid "$guid" -c '{ version, msgtype, guid: $guid, appclientid: $appname, appuserid: $userid }')
- 10 echo $msg >&3
- 11 local ret=$?
- 12 echo "send 103 msg to gcm $ret" >> log.txt
- 13 if [ $ret -ne 0 ]; then
- 14 echo "connection break, send failed"
- 15 exit 3
- 16 fi
- 17
- 18 # no response for 103 message
- 19 echo "$1 offline success! userid=$2"
- 20 }
- 21
- 22 # -2nd offline GCMPopBox/GUX/GSUP
- 23 send_request_103 "GCMPopBox" "$hardid" "$devid"
- 24 send_request_103 "GUX" "$devid" "$devid"
- 25 send_request_103 "GSUP" "$devid" "$devid"
这个过程封装在 send_request_103 函数中，其中 103 是产品下线的消息号。和产品上线消息相比，不用再提供产品版本了，其它方面大同小异。在机器下线前，需要对之前上线的几个客户端服务产品一一下线（GCMPopBox / GUX / GSUP）。除了固定的产品，用户也可以在命令行指定某个产品去上线，这个工具跑起来后长这个样子：
红框中的部分其实是一个循环，用户可以不停的输入要上下线的产品进行操作，这部分的代码相应的也位于一段 while 循环中：
- 1 # online/offline products
- 2 while :
- 3 do
- 4 echo "-------------------------------------------"
- 5 echo -n "product name to operate (exit|quit to quit): "
- 6 read product
- 7 if [ "$product" == "exit" -o "$product" == "quit" ]; then
- 8 break;
- 9 fi
- 10
- 11 echo -n "operation (online|offline): "
- 12 read resp
- 13 online=0
- 14 case "$resp" in
- 15 ""|"o"|"O"|"on"|"ON"|"online"|"ONLINE")
- 16 online=1
- 17 ;;
- 18 *)
- 19 ;;
- 20 esac
- 21
- 22 if [ $online == 1 ]; then
- 23 echo -n "version: "
- 24 read version
- 25 fi
- 26
- 27 echo -n "user id: "
- 28 read userid
- 29
- 30 if [ $online == 1 ]; then
- 31 send_request_102 "$product" "$version" "$userid" "$devid"
- 32 else
- 33 send_request_103 "$product" "$userid" "$devid"
- 34 fi
- 35
- 36 sleep 1
- 37 done
下面做个简单讲解：
- line 4-9：如果用户输入 quit 或 exit，退出循环从而退出整个脚本。否则收集到要操作的产品标识；
- line 11-20：提示用户输入进行何种操作，上线 or 下线；
- line 22-25：如果是上线操作，则需要用户输入产品版本；
- line 27-28：提示用户输入用户 ID；
- line 30-34：根据用户输入的操作类型，调用前面封装好的函数来完成产品上下线。
接收推送消息
产品上线成功后，就可以接收来自后台的“问候”了。这块和前面那种一问一答模式不一样，需要异步处理连接上到达的数据。我的第一反应就是开个线程来处理，但是 shell 里并没有线程这种东西，只有子进程可以用。问题是开子进程后原句柄 (3) 还能代表以前的连接吗？在 linux 上这一点不容置疑，但是 windows 上可没有 fork 这东东啊，怎么保证新启动的子进程复制父进程的用户空间呢？带着疑问，我尝试了下面的代码：
- 1 echo "connect with server"
- 2 on_recv &
- 3 cpid=$!
将接收消息相关代码封装在 on_recv 函数中，就可以直接用 ‘&’ 启动一个单独的进程去跑这个函数啦！作为测试，一开始我只在 on_recv 中处理了几个简单的应答消息（100->201,102->301……）：
- 1 function on_recv
- 2 {
- 3 # can not break read !
- 4 #trap "echo recv exit signal from parent" INT
- 5 while :
- 6 do
- 7 #read msg <&3
- 8 #msg=$(tail -f <&3)
- 9 #read -t 1 msg <&3
- 10 local msg=""
- 11 read -d '}' msg <&3
- 12 if [ -z "$msg" ]; then
- 13 echo -e "\nconnection break, receive failed"
- 14 exit 3
- 15 fi
- 16
- 17 msg="$msg}"
- 18 local type=$(echo "$msg" | jq -r '.msgtype')
- 19 case "$type" in
- 20 "201")
- 21 local guid=$(echo "$msg" | jq -r '.guid')
- 22 echo "online success! devid=$guid"
- 23 ;;
- 24 "301")
- 25 local appname=$(echo "$msg" | jq -r '.appclientid')
- 26 local userid=$(echo "$msg" | jq -r '.dstuserid')
- 27 echo "$appname online success! userid=$userid"
- 28 ;;
- 29 *)
- 30 echo "unknown response type: $type"
- 31 #exit
- 32 ;;
- 33 esac
- 34 done
- 35 }
收到这几个应答消息时，会将其中关键的字段打印在屏幕上。应答消息同请求消息一样，也是纯 json 格式，因此这里使用 jq 来做解析 (line 17-33)。
不过难点倒不在这儿，真正让我费了半天劲儿的地方是在读取，可能有人说了，读取有什么难的，直接 read 不就行了吗？我一开始就是这样做的 (line 7)，然而 read 会一直卡在那里读数据，即使已经有消息读到了也不返回。简单分析一下：看起来 read 在等一个结束标志，一般而言就是换行 '\n'，这也是为什么你可以一直在 console 界面输入内容、直到回车结束的原因。然而后台应答消息并没有换行符作为消息结束，于是我尝试了另外一个方案，使用 tail -f 读取连接中的内容 (line 8)，然而没有任何改进。
因此这里我又试了第三个方案 (line 9)，为 read 增加了一个超时时间 (1s)，这样当时间足够长了以后也能返回之前读到的消息，缺点是 read 会每隔一秒中断一次；然而我忽略了一个更严重的问题的，那就是当产品积压了很多消息没有推送后，当它上线的一刻后台会同时给它推送多个消息，这样一来，这个带超时的 read 常常会将多个消息粘在一起返回，导致后面的解析出错。
于是我试了现在这个方案 (line 11)，告诉 read 一直读、直到遇到 json 结尾符 '}'。当然这也不是完全保险的，因为 json 中有可能存在嵌套的子结构、导致内部含有 ‘}’，但好在现有的协议中应答消息都比较简单，基本上一对花括号之内不会再有花括号了，所以可以这样搞。这个脚本跑起来的效果，其实前面那张图已经展示过了，这次重新划一下重点：
可以看到，新的子进程可以很好的收到机器和产品上线的应答消息（下线没有应答消息），看起来就像它与父进程共享了这个连接一样。验证了 msys2 这个功能没问题后，下面就开始我们的重头戏了 —— 接收后台推送的消息：
- 1 "105")
- 2 local guid=$(echo "$msg" | jq -r '.guid')
- 3 local appclientid=$(echo "$msg" | jq -r '.appclientid')
- 4 local msgid=$(echo "$msg" | jq -r '.msgid')
- 5 local msgbody=$(echo "$msg" | jq -r '.msgbody')
- 6 local appuserid=$(echo "$msg" | jq -r '.appuserid')
- 7 local dstuserid=$(echo "$msg" | jq -r '.dstuserid')
- 8 echo ""
- 9 echo "*******************************************"
- 10 echo "receive customer message "
- 11 echo "product: $appclientid"
- 12 echo "userid : $appuserid"
- 13 echo "msgid : $msgid"
- 14 local body_utf8=$(echo "$msgbody" | base64 -d)
- 15 local body=$(echo "$body_utf8" | iconv -f utf-8 -t gb2312)
- 16 echo "content: $body"
- 17 echo "*******************************************"
- 18 send_request_108 "$guid" "$appclientid" "$appuserid" "$msgid"
- 19 ;;
这里直接上 case 语句。105 是自定义消息，这个应用自己“偷摸”处理掉就好啦，不用给用户展示，这边出于演示目的直接将消息内容打印在屏幕上（有一些 base64 解码及 utf8 编码转换的工作：line 14-15）。收完消息后，给后台回复一个 108 消息表示成功接收，send_request_108 与其它 send 函数大同小异，这里不展开说明了。真正复杂的部分是接收弹窗消息：
- 1 "401")
- 2 local guid=$(echo "$msg" | jq -r '.guid')
- 3 local appclientid=$(echo "$msg" | jq -r '.appclientid')
- 4 local msgid=$(echo "$msg" | jq -r '.msgid')
- 5 local msgbody=$(echo "$msg" | jq -r '.msgbody')
- 6 local appuserid=$(echo "$msg" | jq -r '.appuserid')
- 7 local dstuserid=$(echo "$msg" | jq -r '.dstuserid')
- 8 echo ""
- 9 echo "*******************************************"
- 10 echo "receive popup message "
- 11 echo "product: $appclientid"
- 12 echo "userid : $appuserid"
- 13 echo "msgid : $msgid"
- 14 echo ""
- 15 local body=$(echo "$msgbody" | base64 -d)
- 16 local title_utf8=$(echo "$body" | jq -r '.title')
- 17 local title=$(echo "$title_utf8" | iconv -f utf-8 -t gb2312)
- 18 local content_utf8=$(echo "$body" | jq -r '.content')
- 19 local content=$(echo "$content_utf8" | iconv -f utf-8 -t gb2312)
- 20 local ctxurl=$(echo "$body" | jq -r '."content-url"') # - is not recognized
- 21 local image=$(echo "$body" | jq -r '.image')
- 22 local imgurl=$(echo "$body" | jq -r '."image-url"') # - is not recognized
- 23 echo "title : $title"
- 24 echo "content: $content"
- 25 echo "ctxurl : $ctxurl"
- 26 echo "image : $image"
- 27 echo "imgurl : $imgurl"
- 28 echo "*******************************************"
- 29
- 30 # prepare 108 message
- 31 send_request_108 "$guid" "$appclientid" "$appuserid" "$msgid"
- 32 sleep 1
- 33 # prepare 402 message
- 34 send_request_402 "$msg" "$hardid"
- 35 ;;
401 就是弹窗消息，本来是要给用户在屏幕右下角弹个小窗显示的，这里为了简化问题，也直接打印在屏幕上。收到 401 消息后要先给后台回复一个 108 表示成功接收，再回复一个 402 来表示弹窗最终结果，例如用户点击、关闭、查看详情…等等，这里直接返回用户关闭作为模拟。下面是产品上线后，收到推送消息的效果：
这里演示了两个消息，分别是弹窗消息与自定义消息，可以看到都能正常的解析与显示。后台也可以正常的统计到这两个消息的推送情况：
最后，当用户退出操作循环后，需要及时回收子进程：
- 1 exec 3>&-
- 2 kill -INT $cpid
- 3 wait
这里通过 kill 产生 INT 消息来通知子进程退出接收循环，接着通过 wait 等待子进程完全退出。之前也尝试在子进程中捕获 (trap) INT 信号并优雅的退出，但是发现在 windows 环境下加了这个捕获反而导致 read 不能被中断了，so 放弃之。现在这种方式可能是直接把子进程给杀死了，虽然“暴力”一点，但是起码可以正常工作。
后记
通过构建这个小工具，我甚至发现了协议文档中书写错误或不详的地方。不过最让我感到好奇的还是 —— windows 上是怎么实现两个进程共享一个连接句柄的? 为了解答这个问题，祭出 procexp 大杀器：
可以看到连接只在父进程(20612)中展示，子进程(16844)中并没有对应的连接，那它是怎么在连接上读数据的呢？左看右看没有看出什么头绪。想用 msys2 的 lsof 命令查看下进程句柄，但是翻遍了安装目录也没有找到这个命令，看来 msys2 也不是移植了所有的命令。不过好在 lsof 也是通过 proc 文件子系统实现的，那能不能查看进程的 proc 目录呢？答案是可以的：
- $ ls -l /proc
- total 0
- dr-xr-xr-x 3 yunh 1049089 0 11月 24 14:47 16796/
- dr-xr-xr-x 3 yunh 1049089 0 11月 24 13:35 17992/
- dr-xr-xr-x 3 yunh 1049089 0 11月 24 14:47 18468/
- dr-xr-xr-x 3 yunh 1049089 0 11月 25 15:36 20828/
- dr-xr-xr-x 3 yunh 1049089 0 11月 24 13:35 7464/
- -r--r--r-- 1 yunh 1049089 0 11月 25 15:36 cpuinfo
- lrwxrwxrwx 1 yunh 1049089 0 11月 25 15:36 cygdrive -> //
- -r--r--r-- 1 yunh 1049089 0 11月 25 15:36 devices
- -r--r--r-- 1 yunh 1049089 0 11月 25 15:36 filesystems
- -r--r--r-- 1 yunh 1049089 0 11月 25 15:36 loadavg
- -r--r--r-- 1 yunh 1049089 0 11月 25 15:36 meminfo
- -r--r--r-- 1 yunh 1049089 0 11月 25 15:36 misc
- lrwxrwxrwx 1 yunh 1049089 0 11月 25 15:36 mounts -> self/mounts
- dr-xr-xr-x 2 yunh 1049089 0 11月 25 15:36 net/
- -r--r--r-- 1 yunh 1049089 0 11月 25 15:36 partitions
- dr-xr-xr-x 8 yunh 1049089 0 11月 25 15:36 registry/
- dr-xr-xr-x 8 yunh 1049089 0 11月 25 15:36 registry32/
- dr-xr-xr-x 8 yunh 1049089 0 11月 25 15:36 registry64/
- lrwxrwxrwx 1 yunh 1049089 0 11月 25 15:36 self -> 20828/
- -r--r--r-- 1 yunh 1049089 0 11月 25 15:36 stat
- -r--r--r-- 1 yunh 1049089 0 11月 25 15:36 swaps
- drwxrwx--- 1 Administrators 18 0 11月 25 15:36 sys/
- dr-xr-xr-x 2 yunh 1049089 0 11月 25 15:36 sysvipc/
- -r--r--r-- 1 yunh 1049089 0 11月 25 15:36 uptime
- -r--r--r-- 1 yunh 1049089 0 11月 25 15:36 version
这是我在另一个终端中打印的内容。不过找了一下，没有找到上面两个进程 ID 对应的目录。那在脚本里直接打印呢？
其中 self 就是指自己啦。将这句代码分别放置在父进程连接建立后的位置与子进程 on_recv 函数开头中，得到下面的输出：
- connect with server
- total 0
- lrwxrwxrwx 1 yunh Domain Users 0 Nov 25 15:31 0 -> /dev/null
- lrwxrwxrwx 1 yunh Domain Users 0 Nov 25 15:31 1 -> /dev/cons0
- lrwxrwxrwx 1 yunh Domain Users 0 Nov 25 15:31 2 -> /tools/gsupgo/error.txt
- lrwxrwxrwx 1 yunh Domain Users 0 Nov 25 15:31 3 -> socket:[1]
- lrwxrwxrwx 1 yunh Domain Users 0 Nov 25 15:31 4 -> /proc/8532/fd
- total 0
- lrwxrwxrwx 1 yunh Domain Users 0 Nov 25 15:31 0 -> /dev/cons0
- lrwxrwxrwx 1 yunh Domain Users 0 Nov 25 15:31 1 -> /dev/cons0
- lrwxrwxrwx 1 yunh Domain Users 0 Nov 25 15:31 2 -> /tools/gsupgo/error.txt
- lrwxrwxrwx 1 yunh Domain Users 0 Nov 25 15:31 3 -> socket:[1]
- lrwxrwxrwx 1 yunh Domain Users 0 Nov 25 15:31 4 -> /proc/15580/fd
上面一段是父进程的输出，句柄 3 对应的确实是 tcp 连接；下面一段是子进程的输出，看起来与父进程无异。最有意思的是两个进程的 4 号文件句柄，显示出了它们各自的 pid，显然和它们在 windows 上的进程 ID 是不一样的。这也可能是之前我在 /proc 目录下找不到它们的原因吧。但是再次查看 /proc 目录，仍然没有上面两个 pid，可见这个 pid 可能只是局限于本进程组的 (?)，并不是全局共享，因而也没有什么利用价值。
探索到这就走到死胡同了，有了解 msys2 在 windows 上实现的大神请不吝赐教。
最后这个小工具没有资源可供下载 —— 涉及到公司内部协议安全的问题。不过写了这么多，相信拿来改改写一个自己的也不是什么难事了吧~
参考
[1]. Linux shell脚本中发起tcp、udp连接
[2]. netstat--查看服务器[有效]连接数--统计端口并发数--access.log分析
[3]. jq add or update a value with multiple --arg
经验首页