<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[eigenartiges TServerSocket verhalten]]></title><description><![CDATA[<p>hola leute</p>
<p>bin grad dabei etwas code umzuschreiben und bin beim TServerSocket auf ein eigenartiges verhalten gestossen.</p>
<p>bis jetzt hatte ich das lesen von einem client im TServerSocket immer folgenden aufbau gehabt:<br />
ReceiveLength auslesen und dann in einem rutsch die anzahl von bytes in einen buffer schreiben. hats noch nie probleme gegeben.<br />
nachdem in meinem protokoll die ersten 2 bytes die groesse des geschickten bytes angeben hab ich folgendes gemacht:<br />
erten beiden bytes auslesen. nachgucken wieviel bytes gesammt, davon 2 bytes abziehen und den rest in den buffer schreiben.<br />
ansich macht er das ja auch so. jedoch wird gleich nach dem ersten OnClientRead das gleiche nochmal aufgerufen.<br />
ReceiveLength zeigt dann natuerlich 0 bytes an. verstaendlich. aber wieso macht der das ??<br />
muss man mit ReceiveBuf den gesammten buffer immer auf einen rutsch auslesen ?</p>
<p>hier noch kurz die funktion die das machen sollte:</p>
<pre><code class="language-cpp">unsigned int RecvStream::LoadFromSocket(TCustomWinSocket *t_socket)
   {
      pos = 0; // brauch ich beim auslesen des buffers, hier unwichtig
      uint32 temp = t_socket-&gt;ReceiveLength(); // beim ersten mal stimmts, dann 0
      uint16 t_size = 0;
      t_socket-&gt;ReceiveBuf(&amp;t_size, sizeof(uint16));
      t_socket-&gt;ReceiveBuf(buffer + sizeof(uint16), t_size - sizeof(uint16));
   }
</code></pre>
<p>diese funktion wird von meiner OnClientRead aufgerufen.</p>
<p>jemand ne idee woran das liegen koennte ?</p>
<p>Meep Meep</p>
]]></description><link>https://www.c-plusplus.net/forum/topic/115492/eigenartiges-tserversocket-verhalten</link><generator>RSS for Node</generator><lastBuildDate>Thu, 23 Jul 2026 09:41:34 GMT</lastBuildDate><atom:link href="https://www.c-plusplus.net/forum/topic/115492.rss" rel="self" type="application/rss+xml"/><pubDate>Fri, 15 Jul 2005 07:46:57 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to eigenartiges TServerSocket verhalten on Fri, 15 Jul 2005 07:46:57 GMT]]></title><description><![CDATA[<p>hola leute</p>
<p>bin grad dabei etwas code umzuschreiben und bin beim TServerSocket auf ein eigenartiges verhalten gestossen.</p>
<p>bis jetzt hatte ich das lesen von einem client im TServerSocket immer folgenden aufbau gehabt:<br />
ReceiveLength auslesen und dann in einem rutsch die anzahl von bytes in einen buffer schreiben. hats noch nie probleme gegeben.<br />
nachdem in meinem protokoll die ersten 2 bytes die groesse des geschickten bytes angeben hab ich folgendes gemacht:<br />
erten beiden bytes auslesen. nachgucken wieviel bytes gesammt, davon 2 bytes abziehen und den rest in den buffer schreiben.<br />
ansich macht er das ja auch so. jedoch wird gleich nach dem ersten OnClientRead das gleiche nochmal aufgerufen.<br />
ReceiveLength zeigt dann natuerlich 0 bytes an. verstaendlich. aber wieso macht der das ??<br />
muss man mit ReceiveBuf den gesammten buffer immer auf einen rutsch auslesen ?</p>
<p>hier noch kurz die funktion die das machen sollte:</p>
<pre><code class="language-cpp">unsigned int RecvStream::LoadFromSocket(TCustomWinSocket *t_socket)
   {
      pos = 0; // brauch ich beim auslesen des buffers, hier unwichtig
      uint32 temp = t_socket-&gt;ReceiveLength(); // beim ersten mal stimmts, dann 0
      uint16 t_size = 0;
      t_socket-&gt;ReceiveBuf(&amp;t_size, sizeof(uint16));
      t_socket-&gt;ReceiveBuf(buffer + sizeof(uint16), t_size - sizeof(uint16));
   }
</code></pre>
<p>diese funktion wird von meiner OnClientRead aufgerufen.</p>
<p>jemand ne idee woran das liegen koennte ?</p>
<p>Meep Meep</p>
]]></description><link>https://www.c-plusplus.net/forum/post/831558</link><guid isPermaLink="true">https://www.c-plusplus.net/forum/post/831558</guid><dc:creator><![CDATA[Meep Meep]]></dc:creator><pubDate>Fri, 15 Jul 2005 07:46:57 GMT</pubDate></item></channel></rss>