coolq-http-api
coolq-http-api copied to clipboard
有没有办法通过反向 WebSocket 获取语音文件内容
目前好像只能获取到语音文件名,获取 data 目录下文件的 api 也没有找到反向 websocket 怎么使用…
目前确实没有办法通过正向和反向 WebSocket 来获取 data 目录的内容,这可能需要考虑一下
不知道 WebSocket 在一个很大的 message 在连接上传输的情况下能不能同时传输其它内容,如果能的话,可以做一下,不能的话这可能会造成在获取语音文件的时候无法处理其它请求
还有一个问题,用 WebSocket 往回发文件,似乎无法标记对应的请求了?除非把文件 Base64 之后放在 JSON 里,或者还有另一种办法,让插件直接给某个指定的 HTTP 地址上传文件,这个还需要想一想。
最近剛好對 WebSocket 有些許著墨。
不知道 WebSocket 在一个很大的 message 在连接上传输的情况下能不能同时传输其它内容,如果能的话,可以做一下,不能的话这可能会造成在获取语音文件的时候无法处理其它请求
如果能理解 TCP Flow control 應該就不難理解,TCP 封包是有序的,語音文件的封包發完之前,只有同一個 receive window 下的封包可以發的吧。
不過語音文件發送的方向是由插件到用戶後端,不應該影響到處理請求(後端向插件)的吧?除非插件端用的是阻斷式 socket,必須等待文件寫入底層 buffer,才能回頭來處理請求?
除非把文件 Base64 之后放在 JSON 里
或是~把 JSON 資料轉成二進制跟文件一起發~(這肯定困擾很多開發者 😆) 畢竟 WebSocket 封包類型依編碼分為 utf8 或是二進制,只能選一個。
也可以參考 socket.io 的思路。
socket.io 在發送含有二進制內容的 JSON 時,會先用一個對象當作佔位符頂替二進制的部分(如:原先要發送的對象為["bin", <binary_data>]
,則替換為 ["bin", { num: 0, _placeholder: true }]
),並在下一個封包發送二進制內容(TCP 是有序的,只要確保 socket.write
的調用順序就沒問題的吧)。
不過語音文件發送的方向是由插件到用戶後端,不應該影響到處理請求(後端向插件)的吧?除非插件端用的是阻斷式 socket,必須等待文件寫入底層 buffer,才能回頭來處理請求?
我隐约记得 WebSocket 是会建立两个通道,一个来一个去?如果是这样的话,调用 API 请求文件之后,文件占用了插件到后端的通道,此后的 API 调用虽然可以成功,但后端会潜在地需要很久之后才收到调用结果?