socket non bloquant ????

Marsh Posté le 20-06-2003 à 19:54:13

Bonjour,

je voulais juste une petite confirmation ...
le mode non connecté est il un mode connecté ....

J'aimerais faire un tetris a 2 et je n'aimerai pas qu'une machine attende en position d'ecoute avec un listen().
J'aimerais que les ordi puissent continuer a faire défiler les briques et qu'elle puisse ecouter en meme tps ....

le mode non connecté est il la solution a mon problème ou serais je obligé de me prendre la tete a faire des thread sous borland en C++ pour executer en tache de fond un listen()
http://www.commentcamarche.net/sockets/sockcomm.php3

Sinon que faudrait il que je fasse ???

Reply

Marsh Posté le 20-06-2003 à 19:54:13

Reply

Marsh Posté le 20-06-2003 à 19:57:05

Citation :

le mode non connecté est il un mode connecté ....

:lol:
non

Pour ton pb, t'as qu'à utiliser des sockets non bloquant, va voir les fonctions WSAxxx sous Windows ou bien continue à utiliser les fonctions "normales" en les encapsulant dans des threads.

Reply

Marsh Posté le 20-06-2003 à 19:59:13

le plus facile, avec 1 seul thread :
tu établis la connection avant le début de la partie.
lorsque la partie est commencée, pour savoir si des données sont ds la socket, tu utilises un select (bloquant mais avec possibilité de timer pour le quitter).

mais le plus logique, c'est évidemment avec 2 threads, mais ca devrait etre possible avec 1 seul...

Reply

Marsh Posté le 20-06-2003 à 22:10:00

sinon avec FD_SET, FD_ZERO et FD_ISSET, tu passes tes sockets en non bloquant à grand coup de "select" sans problèmes !

Reply

Marsh Posté le 20-06-2003 à 22:29:25

+ 1 pour la soluce multi-thread. tu peux meme en faire plein, ça te simplifiera aussi la programmation

Reply

Marsh Posté le 20-06-2003 à 22:33:32

++Taz a écrit :

+ 1 pour la soluce multi-thread. tu peux meme en faire plein, ça te simplifiera aussi la programmation

mouais...

j'aurais dit ca aussi d'habitude, mais la ca fait bien 8h ke je bloque sur un pb de deadlock dans un serveur, qui comprend juste 5 threads. Le code est a moitié a moi alors ca m'aide pas non plus à trouver l'origine du bug.

trop de critical sections, c'est tout ce que j'ai a dire...

Reply

Marsh Posté le 20-06-2003 à 22:47:01

petite remarque je programme sous borland5 en c++ sous windows, je veux bien des trucs portable uniquement sous windows ...

le top serait en effet de faire un thread qui s'occupe du listen() ms j'ai jms programme un thread je sais pas si c compliqué

j'ai vu sur internet qu'il y avait les fonctions WSAAsyncSelect(),WSAAsyncGetHostByAddr(), WSAAsyncGetHostByName(), WSAAsyncGetProtoByNumber() qui permettrait de faire des socket asynchrones (pour faire des socket ds les 2 sens). Qu'est que vous en pensez ???

sinon y a ca :
ioctlsocket(sd, FIONBIO, &argp);
je crois que cela permet de rendre une socket non bloquant...
ms je comprends pas trop car c'est au niveau du listen vu le code source :

Code :

bool non_bloquante(SOCKET sd) {
u_long argp=1;
ioctlsocket(sd, FIONBIO, &argp);
if (argp==0) {
fprintf(stderr, "socket non-bloquante, deuxième tentative\n" );
ioctlsocket(sd, FIONBIO, &argp);
}
if (argp==0) {
fprintf(stderr, "n'arrive pas à créer une socket non-bloquante\n" );
return false;
}
return true;
}
Le code typique est le suivant:
while (ret=recv(sd, temp, TEMP_LEN, 0)) {
if (ret==SOCKET_ERROR) {
if (WSAGetLastError()!=WSAEWOULDBLOCK) {
fprintf(stderr, "une erreur est survenue\n" );
break;
} else fprintf(stdout, "." );
} else while(--ret<0) fprintf(stdout, "#" );
}

sinon le select() permettrait de connaitre l'état de la socket, ms ca veut dire quoi ca justemment ??????
je comprends pas trop la remarque de Kyle_Katarn qui me dit que le select me permettrait de passait en non bloquant alors que c'est juste pour etre informé de l'état le select()

pour vous quel serait la methode la plus simple que vous avez tester ????

Message édité par weed le 20-06-2003 à 22:51:54

Reply

Marsh Posté le 20-06-2003 à 22:55:16

weed a écrit :

sinon le select() de connaitre l'état de la socket, ms ca veut dire quoi ca justemment ??????
je comprends pas trop la remarque de Kyle_Katarn qui me dit que le select me permettrait de passait en non bloquant

select te permet effectivement de connaitre "l'etat" d'une ou plusieurs sockets. cette fct n'est pas bloquante si tu lui passes un timeout (par ex de 50 ms), car si au bout de ces 50 ms rien ne s'est passé, elle retourne 0 ce qui te permet de traiter d'autre données. par contre si une socket contient des données, le select retourne sans attendre les 50 ms.

donc ca serait possible de mettre tout le bordel dans 1 seul thread, de cette manière :

Code :

while ()
{
int ret = select(); // pour voir si y a des données ds la socket
if (données ds une socket)
recv()
// autre code (par ex affichage)
}

la seule condition étant de passer par le select un minimum de fois par seconde.

a mon avis c'est pas la meilleure solution, mais ptet la plus simple si t'as vraiment pas envie de faire des freds.

edit : petite précision, les sockets sont ici bloquantes mais aucune fct n'est bloquante donc le pb se pose pas.

Message édité par Konar le 20-06-2003 à 22:56:53

Reply

Marsh Posté le 21-06-2003 à 10:09:13

Voilà un morceau de code du serveur SMTP que j'ai codé :

Code :

while ((nRet != SOCKET_ERROR) && (msg->Find("\n",0)==-1))
{
FD_ZERO(&rd);
FD_SET(sck,&rd);
select(sck+1,&rd,(fd_set *) 0, (fd_set *) 0,&t);
if (FD_ISSET(sck, &rd))
{
nRet=recv(sck,buf.GetBuffer(255),255,0);
buf.ReleaseBuffer();
if ((nRet != SOCKET_ERROR) && (nRet!=0))
(*msg)+=buf.Left(nRet);
else
return false;
}
else
{
return false;
}
buf.Empty();
if (b_exit) return false;
}

J'espère que ça explique clairement l'usage des FD_ISSET et autres...

Reply

Marsh Posté le 21-06-2003 à 13:13:20

oui, il faut un seul thread, et utiliser select
comme select te dit s'il y a des infos a lire, le recv ne bloque pas.

Reply

Marsh Posté le 21-06-2003 à 13:13:20

Reply

Marsh Posté le 21-06-2003 à 13:16:29

bien sûr le multithreading marche aussi mais c'est une solution de facilité qui est généralement mal employée par ceux qui l'utilisent.

Reply

Marsh Posté le 24-06-2003 à 00:35:31

c kler de chez clair que ca serait le top
j'ai trouvé 2-3 truc nottamment sur la msdn
http://www.microsoft.com/belux/fr/ [...] read1.mspx
et ca
http://www.flipcode.com/tutorials/tut_mthreading.shtml

j'ai pas trop regardé a ce qui parait y a plein de poonteurs chose que j'aime pas trop ....

j'ai vu aussi je ne sais plus ou un tuto thread, mais j'ai vu qu'il y avait un fork. et le fork ca permet de dupliquer un processus et de savoir si on est le pere ou le fils par le PID qu'il retourne... Dc c tottallement different C et C++ j'ai l'impression .....

J'en ai jms fait c compliqué ou pas ????
et surtout si vous pour moi des exemples le plus basics possibles pour expliquer

sinon si je n'y arrive je ferais un petit select () ms ca ferait plaisir de savoir creer un thread ms bon si ca me prends trop de tps je laisserai tomber.

Reply

Marsh Posté le 24-06-2003 à 01:41:11

exemple a la con :

Code :

#include <windows.h>
DWORD WINAPI Thread_Rien(LPVOID lpParameter)
{
int i = (int)lpParameter;
while (i--)
{
MessageBox(0, "Thread", "", 0);
Sleep(1000);
}
return 1;
}
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
DWORD dwThreadId;
HANDLE hThread = CreateThread(NULL, 0, Thread_Rien, (LPVOID)10, 0, &dwThreadId);
DWORD dw = WaitForSingleObject(hThread, 5000);
if (dw == WAIT_TIMEOUT)
TerminateThread(hThread, 0);
return 0;
}

lis vite fait la doc sur les fct CreateThread, WaitForSingleObject et GetExitCodeThread, et tu devrais vite voir le principe du bordel.

Reply

Marsh Posté le 24-06-2003 à 02:02:51

humm hulll oki

j'ai pas encore fini mon tetris en solo, ma class file_d'attente et oui je pourrais faire tomber plusieurs brique en meme tps et 2-3 trucs et apres je me jette sur les threads ....

et je ferais remonté le topic si je 2-3 questions sur les threads

oki pour WaitForSignalObject()

Citation :

L'événement signalé
// ===================
//
// c'est un mécanisme permettant de réaliser une attente passive (i.e. sans
// utiliser de temps sur le processeur). Tout comme pour la section critique,
// il s'agit d'un objet spécialisé optimisé pour attendre d'être signalé,
// comportement que l'on pourrait obtenir là aussi avec une sémaphore.
//
// utilisation typique :
// une tâche T1 réalise un travail puis signal S
// une tâche T2 attend S puis réalise un travail
//
// création du signal par CreateEvent()
// suppression du signal par CloseHandle()
// attente du signal par WaitForSingleObject()
// envoie du signal par SetEvent()
//
// notez qu'une tache se terminant, elle signale son état, ce qui permet
// à une autre tache éventuellement en attente avec WaitForSignalObject()
// de poursuivre son exécution

http://perso.wanadoo.fr/dgil/ftp/coiffeur_cpp.txt

GetExitCodeThread,
The GetExitCodeThread function retrieves the termination status of the specified thread.
ca permet de recuperer le thread qd il est terminé ou pas, c quoi ce termination ....
http://msdn.microsoft.com/library/ [...] thread.asp

bon j'y regarderé plus tard sur les thread qd mon programmes sera oki ...

Reply

Marsh Posté le 24-06-2003 à 17:08:20

Kyle_Katarn :
J'espère que ça explique clairement l'usage des FD_ISSET et autres...

bin ... pour moi c'est pas clair du tout ... tu aurais un tit tuto/cours la dessus ?

---------------
-( BlackGoddess )-

Reply

Marsh Posté le 24-06-2003 à 17:25:03

Konar a écrit :

j'aurais dit ca aussi d'habitude, mais la ca fait bien 8h ke je bloque sur un pb de deadlock dans un serveur, qui comprend juste 5 threads. Le code est a moitié a moi alors ca m'aide pas non plus à trouver l'origine du bug.

trop de critical sections, c'est tout ce que j'ai a dire...

Langage de spécification formel et preuve -> utiliser les outils adaptés au problème ....

Reply

Marsh Posté le 24-06-2003 à 17:32:07

BlackGoddess a écrit :

Kyle_Katarn :
J'espère que ça explique clairement l'usage des FD_ISSET et autres...

bin ... pour moi c'est pas clair du tout ... tu aurais un tit tuto/cours la dessus ?

Non mais le MSDN l'explique assez clairement il me semble.
Avec un pote on a monté tout un serveur SMTP qui tiend bien (plusieurs centaines de réception et envois simultannéements multithreadés) avec uniquement ça. Donc si on l'a fait ça doit pas être trop dur de comprendre.... (au pire je peux te filer les bout de code nécessaires)

Reply

Marsh Posté le 24-06-2003 à 17:56:17

nraynaud a écrit :

Langage de spécification formel et preuve -> utiliser les outils adaptés au problème ....

moui... tu pourrais donner plus de précisions ???

pasque la j'ai temporairement résolu le pb du deadlock en virant la plupart des critical sections, je fais pour le moment confiance au "Thread Safety in the Standard C++ Library".

Reply

Marsh Posté le 24-06-2003 à 18:17:24

Konar a écrit :

moui... tu pourrais donner plus de précisions ???

Non, c'est pas mon domaine, c'est en général dans le domaine du temps-réel. Tu vires la partie qui t'intéresse pas et tu garde la partie multi-processus et synchro. Je me souviens plus du nom du moindre langage, ni outil de preuve, et je m'en porte plutôt bien.

Reply

Marsh Posté le 24-06-2003 à 18:28:15

nraynaud a écrit :

Non, c'est pas mon domaine, c'est en général dans le domaine du temps-réel. Tu vires la partie qui t'intéresse pas et tu garde la partie multi-processus et synchro. Je me souviens plus du nom du moindre langage, ni outil de preuve, et je m'en porte plutôt bien.

me demande si on parle de la meme chose la...

j'ai une appli C++ avec plein de threads, qui peuvent éventuellement utiliser (lecture et/ou écriture) les mêmes objets. Je vais pas virer le code comme ca... ca marchera surement moins bien.

enfin bon c'est pas critique comme pb, la stl a l'air de claker a ce niveau.

Reply

Marsh Posté le 24-06-2003 à 22:35:16

Konar a écrit :

Je vais pas virer le code comme ca... ca marchera surement moins bien.

Je te parle de virer la partie qui t'intéresse pas dans la théorie du temps-réel.

Reply

Marsh Posté le 25-06-2003 à 01:32:30

nraynaud a écrit :

Je te parle de virer la partie qui t'intéresse pas dans la théorie du temps-réel.

bah vais faire ca, t'as raison.
apres je compilerais en mode théorie temps réél.

Reply

Marsh Posté le

Reply

socket non bloquant ????

Sujets relatifs:

Leave a Replay