<br><div class="gmail_quote">2008/5/5 Krzysztof Sobolewski <jezuch@interia.pl>:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Marcel Hauf pisze:<br>
<div class="Ih2E3d"><br>
> Yeah, right but .Net provides a TcpClient class to handle a net<br>
> connection easier.<br>
> But I prefer sockets.<br>
<br>
</div>Oh, yeah, I'm not familiar with .NET, obviously...</blockquote><div>No problem. I havenīt figured out by myself all .Net classes and functions yet.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
> The client library receives binary "code" which will be deserialized by<br>
> a BinarySerializer with the help of the protocol library.<br>
> This means the protocol library must be 100% compatible to the server<br>
> protocol library, Iīm correct?<br>
<br>
</div>It's the nature of protocols that the implementation has to be 100%<br>
compatible, isn't it... Parts of libtpproto-java could be used on the server<br>
side, because the wire format, obviously, is the same and only the concrete<br>
frames differ.<br>
But maybe I don't understand the question :)</blockquote><div>Not if it is simple plain text. There you can only pick up the command and left out the attributes.<br>In binary form I think it is not possible to only have a class which gets deserialized which only stores the command and no attributes.<br>
</div></div>It would have been better if I had written it without the question mark(?) (This is not a question).<br><br>~ Marcel Hauf<br>