On 12/20/07, <b class="gmail_sendername">Sean Hefty</b> <<a href="mailto:mshefty@ichips.intel.com">mshefty@ichips.intel.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
My thinking was that the peer to peer model would have both sides call<br>connect only.  The peer to peer connection model only kicks in when both<br>sides are in the REQ sent state.</blockquote><div><br>
Is this observation based on the wording used by the spec? if yes, can you point on the sentence/s that does it? <br>
<br>
>From my reading, I could not conclude that implementing it in a way
that both sides do listen and later set the peer to peer bit on the REQ
such that --if-- there's a "matching" REQ for the incoming REQ one side
sends REP and the other side ignores the incoming REQ etc - is against
the spec.<br>
</div><div><br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> This makes the all peer to peer model useless, since an app can not make<br>> sure that connection occur at exactly the same time!
<br><br>yep - (anyone can feel free to step in a set me straight on this...)<br><br>> the spec is that peer to peer model has the ability to handle also<br>> connections that occur at exactly the same time but not only.
<br><br>Peer to peer seems inherently racy to me</blockquote><div><br>
I understand that under TCP there's also a notion of peer to peer and
client/server connections, I'll give it a look next week to see what's
the foundations over there.<br>
 </div>Or<br></div><br>