PDA

View Full Version : socket callback problem




kevinrichardsuk
Jun 16, 2008, 10:36 AM
Hi,

Hopefully this is just a quick fix.

I've created a socket to recieve data, like so;


- (void) createSocket {

CFSocketRef socket;

socket = CFSocketCreate(kCFAllocatorDefault, 0, 0, 0, kCFSocketDataCallBack, rxData, NULL);


This works fine. My callback function works and I can print to console.


void rxData(CFSocketRef s, CFSocketCallBackType callbacktype, CFDataRef address, const void *data, void *info) {

printf("rx some data\n");
}

The problem I have is that I can't access any of my class variables, they create "undefined variable" errors..


I'm still new to this - any help would be great.



kpua
Jun 16, 2008, 10:45 AM
That's because the callback is a regular C function and doesn't know anything about the ObjC object you want it to communicate with. However, the last 'context' parameter has an 'info' pointer which is used for program-defined data, ie an ObjC object. You can get access to it via this if you set the context appropriately when you create the socket.

kevinrichardsuk
Jun 16, 2008, 11:06 AM
That's because the callback is a regular C function and doesn't know anything about the ObjC object you want it to communicate with. However, the last 'context' parameter has an 'info' pointer which is used for program-defined data, ie an ObjC object. You can get access to it via this if you set the context appropriately when you create the socket.

Do you know where I can find a sample of the appropriate CFSocketContext to get this going?


Again, thanks for the help.

kpua
Jun 16, 2008, 11:52 AM
Just look it up in the docs. It tells you exactly what each field should be. The retain/release callbacks can be used to call -retain or -release on the context's info object as necessary, but you can pass NULL if you don't expect the object to be released before the CFSocket is destroyed.

kevinrichardsuk
Jun 17, 2008, 03:58 AM
Thanks!

kevinrichardsuk
Jun 17, 2008, 09:05 AM
I still can't figure this out - I must have tried everything except the correct line to get this working. I can now get the data to an instance method, but in the process have had to create a new instance and lost the local variable I needed.


CFSocketContext socketCtxt = {0, self, NULL, NULL, NULL};
socket = CFSocketCreate(kCFAllocatorDefault, 0, 0, 0, kCFSocketDataCallBack, MyCallBack, &socketCtxt);


void MyCallBack (CFSocketRef s, CFSocketCallBackType callbacktype, CFDataRef address, const void *data, void *info) {

SocketWrapper *skt = (SocketWrapper *)info;

//Perform method on skt, but delegate var is not correct
}


I have an instance variable called "delegate" which is set correctly when I create the socket, but obviously not when I create skt.

Can anyone help? I understand this is pretty basic but I can't figure out how this callback works..

After 2 days of trying to get this going, I'm more than prepared to buy somebody a round of beers to get this working (via paypal of course..)

kpua
Jun 17, 2008, 09:21 AM
So, you're saying the 'info' parameter is pointing to a valid SocketWrapper object, but the 'delegate' ivar is different in the callback than it is where you create the socket? Sounds strange to me. Try breaking in the debugger on setDelegate: and find out where it's getting changed...

If I were you, I'd double-check that the info parameter is still valid... it might be deallocated in the time between the socket's created and the callback is called, which means you'll need to specify retain/release callbacks as well.

kevinrichardsuk
Jun 17, 2008, 09:44 AM
So, you're saying the 'info' parameter is pointing to a valid SocketWrapper object, but the 'delegate' ivar is different in the callback than it is where you create the socket? Sounds strange to me. Try breaking in the debugger on setDelegate: and find out where it's getting changed...

If I were you, I'd double-check that the info parameter is still valid... it might be deallocated in the time between the socket's created and the callback is called, which means you'll need to specify retain/release callbacks as well.

thanks for that. I may have been chasing the wrong problem for a day, the callback only runs once (at startup), then never again.

I put a test printf statement into a test method on the delegate. That does actually appear to work on the first callback only..