從api開始理解qnx -- 訊息傳遞
1. 頻道與連線
channel, connect
server:
channelid = channelcreate(flags);
client:
connectionid = connectattach(node, pid, chid, index, flag);
node: 機器號; pid是服務程序號; chid就是channelcreate後得到的頻道號.
連線的終止是connectdetach()，而頻道的結束則是channeldestroy()了。不過，一般伺服器都是長久存在的，不大有需要channeldestroy()的時候。
2. 傳送,接收與應答
send, receive, reply
server:
recieveid = msgreceive(channelid, receivebuffer, receivebuflength,&msginfo);
...deal recvd msg....
msgreply(receiveid, replybuf, replylen);
client:
msgsend(connectionid, sendbuf, sendlen, replybuf, replylen);
....然後由os將這個執行緒掛起...
....當伺服器msgreply()後,os解除執行緒阻塞狀態,客戶端可以檢查自己的receivebuf看看應答效果...
3. 資料區與iov
雖然在客戶端header同databuf是兩塊不相鄰的記憶體，但傳遞到伺服器端的receivebuffer裡，就是連續的了。
客戶端: "header" 與 "databuf" 是不連續的兩塊資料。
setiov(&iov[0], &header, sizeof(header));
setiov(&iov[1], databuf, datalen);
msgsendvs(connectionid, iov, 2, replybf, replylen);
伺服器: 接收後，"header"與"databuf"被連續地存在receivebuffer裡。
receiveid = msgreceive(channelid, receivebuffer, receivebuflength, &msginfo);
header = (struct header *)receivebuffer;
databuf = (char *)((char *)header + sizeof(*header));
當指定的receivebuflength小於實際收到的位元組數,即msgreceive不一定讀完了所有來自client的資料,因此還需要檢視msginfo,並使用msgread(receiveid,
receivebuffer+receivebuflength, // 指定存資料buffer起始位址
receivebuflength, // 去緩衝區讀資料時候的偏移量
msginfo->srcmsglen - msginfo->msglen // 未讀取完的資料長度
));
從開源開始
把程式 全部公開是非常符合人性。這大概因為人性是懶惰的。既然能夠用電腦完成，就不要用人來完成。但電腦還是需要人來控制。於是，有眾多的人辛辛苦苦地加入了程式設計師的行列裡。開源後程式設計師也可以懶一些，把除錯 和增加功能交給了大眾。同時獲益的也有大眾，他們可以不做出重複勞動了。是的，多好啊，他們可以不...
WebRTC（一）從了解三個方面的API開始
webrtc是乙個由google發起的實時通訊解決方案，webrtc 雖然底層實現極其複雜，但是面向開發者的api還是非常簡潔的，主要分為三個方面 network stream api rtcpeerconnection datachannel network stream api 主要有兩個api...
理解 API 使用
深入理解apiwindows api 包括上千個函式，主要分為以下幾部分 在我們編寫windows應用程式的利器 define win32 lean and mean include 順序 include include pragma comment lib,ws2 32.lib 鏈結庫window...