Discussion :

[Metal Tom]

Bonjour,

J'essaye de faire communiquer mon appli iPhone avec un serveur TCP à l'aide d'une socket. N'ayant pas d'iPhone sous la main j'utilise le simulateur.

Question : est-ce que le simulateur prend en charge les sockets ? a m'étonnerait fort qu'il ne le fasse pas.

En fait mon serveur ne reçoit jamais la connexion, et encore moins les données. Voici le code pour l'ouverture de la connexion, ça vient grosso modo de la doc Apple.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
- (void)openConnection:(NSString *)url{
	NSLog(@"Opening connection with %@", url);
	if ([url isEqualToString:@""])
		return;
	NSURL *server = [NSURL URLWithString:url];
	if (!server){
		NSLog(@"Bad address: %@", url);
		return;
	}
 
	CFReadStreamRef readStream;
	CFWriteStreamRef writeStream;
	CFStreamCreatePairWithSocketToHost(NULL, (CFStringRef)[server host], 1551, &readStream, &writeStream);
 
	if (readStream == nil || writeStream == nil)
		NSLog(@"Connexion error");
 
	inputStream = (NSInputStream *)readStream;
	outputStream = (NSOutputStream *)writeStream;
	[inputStream setDelegate:self];
	[outputStream setDelegate:self];
	[inputStream scheduleInRunLoop:[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];
	[outputStream scheduleInRunLoop:[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];
	[inputStream open];
	[outputStream open];
	NSLog(@"Should be connected");
 
	[self sendString:@"test"];
}

Et voici ma méthode pour envoyer un message à travers la socket.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
-(void)sendString:(NSString *)string {
	const uint8_t *rawstring = (const uint8_t *)[string UTF8String];
	[outputStream write:rawstring maxLength:strlen(rawstring)];
}

D'après la doc la socket devrait être ouverte quand les streams sont ouverts. Je suis nouveau en Objective-C et développement iPhone, j'ai du mal à saisir la philosophie qui se cache derrière. J'ai l'habitude des sockets en C et Java qui n'ont rien de bien sorcier.

Je précise que les méthodes sont bien appelées et streams semblent être bien instanciés.

Merci d'avance pour votre aide.

[Metal Tom]

Réponse partielle : ne pas passer pas NSURL.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

CFStreamCreatePairWithSocketToHost(NULL, (CFStringRef)url, 1551, &readStream, &writeStream);

Maintenant quand j'écris ça flush pas, le message n'est envoyé que lorsque je quitte l'appli. Je vais regarder du côté du callback.

[JeitEmgie]

Réponse partielle : ne pas passer pas NSURL.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

CFStreamCreatePairWithSocketToHost(NULL, (CFStringRef)url, 1551, &readStream, &writeStream);

Maintenant quand j'écris ça flush pas, le message n'est envoyé que lorsque je quitte l'appli. Je vais regarder du côté du callback.

NSStream open:

"Implement open to open the stream for reading or writing and make the stream available to the client directly or, if the stream object is scheduled on a run loop, to the delegate."

si vous voulez écrire/lire directement, il ne faut pas appeler "scheduleInRunLoop" qui sous-entend que vous avez l'intention de travailler en asynchrone via le "delegate"…

[Metal Tom]

Merci pour ta réponse.
J'ai enlevé les scheduleInRunLoop mais ça ne change rien malheureusement.

J'ai essayé d'utiliser des NSFileHandle à la place comme expliqué là dessus : http://iphonedevelopment.blogspot.co...ions-with.html

Mais sans succès.

[Metal Tom]

Bon à chercher loin on en oublie les bases. Un petit \n à la fin du message envoyé et ça flush.

[JeitEmgie]

Bon à chercher loin on en oublie les bases. Un petit \n à la fin du message envoyé et ça flush.

c'est pas une question de flush… NSOutputStream est "byte-oriented" et ne s'occupe pas de la sémantique du stream de bytes… il ne faut pas croire ou laisser que mettre un "\n" dans un flux provoque un flush.

Ce que vous indiquez comme solution, signifie plutôt que c'est vous qui ne respectiez pas les règles du jeu du logiciel qui écoute à l'autre bout : lui s'attend à recevoir à "\n" comme "fin de ligne" avant de faire quoi que ce soit.