<?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[blocking vs. non-blocking sockets &#x2F; select]]></title><description><![CDATA[<p>Hallo!</p>
<p>Ich bräuchte mal Hilfe und eure Meinung bezüglich blocking / non-blocking sockets.</p>
<p>Mein Projekt:<br />
Auf einen Ping hin melden sich meine Roboter, die im Netzwerk sind. Für jeden Roboter erzeuge ich einen neuen Thread (max. 16). In jedem Thread erzeuge ich einen socket und verbinde ihn zu einem Client/Roboter. Jetzt möchte ich Daten vom Roboter empfangen können. Liegt nichts an, dann soll eventuell ein Zeichen auf Tastendruck gesendet werden.</p>
<pre><code>void threadFunction(void* p){

Robot* localRobo = p;

//main loop
while(localRobo-&gt;exists)
{

	//recv data
	if(recvFromClient() &gt; 0)  
	{
		..do something with the received data
	}

	//send keystroke
	if(localRobo-&gt;KEY_Read())  //reads keystroke (non-blocking)
	{
		..send keystroke to robot
	}

}
}

int recvFromClient()
{
	int received = 0;
	FD_SET fdSet_read;
	timeval timeout;

	timeout.tv_sec=1;	//wait for 1 sec
	timeout.tv_usec=0;

	FD_ZERO(&amp;fdSet_read);
	FD_SET(connectedSocket, &amp;fdSet_read);

	select(0,&amp;fdSet_read,NULL,NULL,&amp;timeout);

	if(FD_ISSET(connectedSocket, &amp;fdSet_read))
	{

		received=recv(connectedSocket,(char*)&amp;buffer[received].....);  	
		.....

	}	

	return received;
}
</code></pre>
<p>Wenn ich einen blockenden socket benutze, dann bleibt der thread beim recv() stehen und wartet auf Daten. Dann kann ich aber nicht zu jeder Zeit eine Tastatureingabe versenden.<br />
Benutze ich nicht-blockende Socket, dann geht es, aber die CPU läuft auf 100%</p>
<p>Ich habe es dann mit select() versucht, aber select() gibt es auch blockend oder nicht-blockend. Und dann habe ich das gleich Problem wieder. Ich habe select auch mit Timeout probiert. Das funktioniert soweit, aber mir gefällt das &quot;polling&quot; nicht.<br />
Für die nicht-blockenden sockets gibt es doch zwei Wege. &quot;Polling&quot; und &quot;asynchron notification&quot;. Das &quot;polling&quot; verursacht aber die hohe CPU Last. Gibt es ein Lösung für &quot;asynchron notification&quot;? Mein Programm ist kein Win32 Programm, also kann ich WSAAsyncSelect() nicht benutzen. Ich habe eigentlich gedacht, dass select() die Lösugn wäre.</p>
<p>Gibt es einen besseren Weg das zu programmieren? Was haltet ihr von der Idee einen Thread für jeden Roboter zu erzeugen? Ich habe mir noch gedacht, zwei Threads pro Roboter zu erzeugen. Einen für das Empfangen von Nachrichten (dann im blockenden Modus um die CPU zu schonen) und einen für das Versenden der Tastatureingabe.</p>
<p>Bin auf eure Meinungen gespannt.<br />
Gruss und ein schönes neues Jahr<br />
Chris</p>
]]></description><link>https://www.c-plusplus.net/forum/topic/96383/blocking-vs-non-blocking-sockets-select</link><generator>RSS for Node</generator><lastBuildDate>Fri, 17 Apr 2026 03:30:25 GMT</lastBuildDate><atom:link href="https://www.c-plusplus.net/forum/topic/96383.rss" rel="self" type="application/rss+xml"/><pubDate>Sat, 01 Jan 2005 07:55:14 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to blocking vs. non-blocking sockets &#x2F; select on Sat, 01 Jan 2005 07:55:14 GMT]]></title><description><![CDATA[<p>Hallo!</p>
<p>Ich bräuchte mal Hilfe und eure Meinung bezüglich blocking / non-blocking sockets.</p>
<p>Mein Projekt:<br />
Auf einen Ping hin melden sich meine Roboter, die im Netzwerk sind. Für jeden Roboter erzeuge ich einen neuen Thread (max. 16). In jedem Thread erzeuge ich einen socket und verbinde ihn zu einem Client/Roboter. Jetzt möchte ich Daten vom Roboter empfangen können. Liegt nichts an, dann soll eventuell ein Zeichen auf Tastendruck gesendet werden.</p>
<pre><code>void threadFunction(void* p){

Robot* localRobo = p;

//main loop
while(localRobo-&gt;exists)
{

	//recv data
	if(recvFromClient() &gt; 0)  
	{
		..do something with the received data
	}

	//send keystroke
	if(localRobo-&gt;KEY_Read())  //reads keystroke (non-blocking)
	{
		..send keystroke to robot
	}

}
}

int recvFromClient()
{
	int received = 0;
	FD_SET fdSet_read;
	timeval timeout;

	timeout.tv_sec=1;	//wait for 1 sec
	timeout.tv_usec=0;

	FD_ZERO(&amp;fdSet_read);
	FD_SET(connectedSocket, &amp;fdSet_read);

	select(0,&amp;fdSet_read,NULL,NULL,&amp;timeout);

	if(FD_ISSET(connectedSocket, &amp;fdSet_read))
	{

		received=recv(connectedSocket,(char*)&amp;buffer[received].....);  	
		.....

	}	

	return received;
}
</code></pre>
<p>Wenn ich einen blockenden socket benutze, dann bleibt der thread beim recv() stehen und wartet auf Daten. Dann kann ich aber nicht zu jeder Zeit eine Tastatureingabe versenden.<br />
Benutze ich nicht-blockende Socket, dann geht es, aber die CPU läuft auf 100%</p>
<p>Ich habe es dann mit select() versucht, aber select() gibt es auch blockend oder nicht-blockend. Und dann habe ich das gleich Problem wieder. Ich habe select auch mit Timeout probiert. Das funktioniert soweit, aber mir gefällt das &quot;polling&quot; nicht.<br />
Für die nicht-blockenden sockets gibt es doch zwei Wege. &quot;Polling&quot; und &quot;asynchron notification&quot;. Das &quot;polling&quot; verursacht aber die hohe CPU Last. Gibt es ein Lösung für &quot;asynchron notification&quot;? Mein Programm ist kein Win32 Programm, also kann ich WSAAsyncSelect() nicht benutzen. Ich habe eigentlich gedacht, dass select() die Lösugn wäre.</p>
<p>Gibt es einen besseren Weg das zu programmieren? Was haltet ihr von der Idee einen Thread für jeden Roboter zu erzeugen? Ich habe mir noch gedacht, zwei Threads pro Roboter zu erzeugen. Einen für das Empfangen von Nachrichten (dann im blockenden Modus um die CPU zu schonen) und einen für das Versenden der Tastatureingabe.</p>
<p>Bin auf eure Meinungen gespannt.<br />
Gruss und ein schönes neues Jahr<br />
Chris</p>
]]></description><link>https://www.c-plusplus.net/forum/post/684096</link><guid isPermaLink="true">https://www.c-plusplus.net/forum/post/684096</guid><dc:creator><![CDATA[cschmitz]]></dc:creator><pubDate>Sat, 01 Jan 2005 07:55:14 GMT</pubDate></item></channel></rss>