• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            S.l.e!ep.¢%

            像打了激速一樣,以四倍的速度運轉(zhuǎn),開心的工作
            簡單、開放、平等的公司文化;尊重個性、自由與個人價值;
            posts - 1098, comments - 335, trackbacks - 0, articles - 1
              C++博客 :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理

            源URL:http://lists.zeromq.org/pipermail/zeromq-dev/2010-February/002383.html

            意思沒太懂,大概就是Z.E.R.O.M.Q主要是針對服務(wù)器間的通信,獲取客戶端連接IP的意義不大

            Hi Fred,
            
            >>> Just one question remains : were can I grab in the server
            >>> environment the IP address and portnumber of the sending client ?
            >> No way to do that at the moment, other than doing it at the app level
            >> (make up a client ID / use the IP address and stick it in the
            >> message).
            
            Let me give some background here.
            
            Simply said: 0MQ should manage connections for you. Your application 
            should be agnostic about exact location/identity of the peers. If you 
            want to work on the level of individual connections, use BSD sockets 
            rather than 0MQ.
            
            More complex answer: The issue has to do with scaling 0MQ into internet 
            scales. What you want to know is the identity of the peer who sent the 
            message. You are not interested in any middleboxes that may be on the 
            way (like zmq_forwarder etc.) Thus, getting IP address we've received 
            the message from is useless - it's IP address of the previous hop. Also, 
            if IP address is used as the identity, two applications running on the 
            same box would look exactly the same. Same application bound to several 
            network interfaces would look different depending on how exactly you are 
            connected to it. Etc.
            
            At the moment, the only thing you can do is to choose a name for your 
            application and fill it into the message. In easy to modify 0MQ to do 
            the thing for you, however, it's not a conceptual solution.
            
            Real solution still requires a lot of research work. Feel free to start 
            the discussion though.
            
            > OK, but that's (at least for me) not thrustworthy. Like SMTP telling me 
            > who they are. ;-)
            
            What you would consider trustworthy, what kind of attacks should it be 
            resistent to, etc.
            
            > You don't mind if I take a look at the sources to see whether it is 
            > doable for me ?
            
            Sure. Go for it. Any experimentation is valuable! The source is licensed 
            under LGPL so you can modify it in any way given that you publish the 
            result under LGPL.
            
            Martin
            66精品综合久久久久久久| 久久久久亚洲AV成人网人人网站| 久久亚洲AV无码精品色午夜| 久久人人添人人爽添人人片牛牛| 欧美一区二区三区久久综合| 国产亚洲综合久久系列| 久久久久无码中| 久久久久久久女国产乱让韩| 粉嫩小泬无遮挡久久久久久| 久久久久无码精品| 久久久无码一区二区三区| 精品久久久久久无码中文字幕| 99久久精品国产一区二区 | 青青草原综合久久大伊人| 久久香综合精品久久伊人| 久久婷婷五月综合97色直播| 国内精品久久人妻互换| 久久丫忘忧草产品| 成人午夜精品久久久久久久小说| 国产精品久久久久久久人人看 | 超级碰碰碰碰97久久久久| 精品999久久久久久中文字幕 | 国产高清美女一级a毛片久久w| 日韩精品久久久肉伦网站| 免费精品国产日韩热久久| 久久97久久97精品免视看秋霞| 国产精品美女久久久久| 亚洲国产精品久久电影欧美| 久久婷婷五月综合97色直播| 青青草国产97免久久费观看| 国产亚州精品女人久久久久久 | 国产福利电影一区二区三区久久久久成人精品综合 | 精品国产乱码久久久久久郑州公司| 一本色道久久综合| 久久免费99精品国产自在现线| 国内精品久久久久久麻豆 | 久久久久久国产精品无码下载 | 色欲久久久天天天综合网精品| 久久久久青草线蕉综合超碰| 久久99九九国产免费看小说| 久久精品桃花综合|