Re: sockets in Powerplant?
Re: sockets in Powerplant?
- Subject: Re: sockets in Powerplant?
- From: Marc Stibane <email@hidden>
- Date: Sat, 18 Oct 2003 02:40:54 +0200
News - now it broadcasts, but doesn't get an answer back.
This is the dump of the non-carbon app running under trueblue:
sudo tcpdump -vvv proto UDP and host 192.168.102.169 and host
\(192.168.102.235 or 255.255.255.255\)
tcpdump: listening on en0
01:41:25.610250 mac-marc.sofha.de.2289 > 255.255.255.255.2288: [udp sum
ok] udp 9 (DF) (ttl 60, id 16, len 37)
01:41:25.610463 192.168.102.235.2288 > mac-marc.sofha.de.2289: [udp sum
ok] udp 25 (DF) (ttl 64, id 0, len 53)
and this is the dump of the carbonized app running native on X:
sudo tcpdump -vvv proto UDP and host 192.168.102.169 and host
\(192.168.102.235 or 255.255.255.255\)
tcpdump: listening on en0
01:42:45.926998 mac-marc.sofha.de.2289 > 255.255.255.255.2288: [udp sum
ok] udp 9 (ttl 64, id 20524, len 37)
no answer here from the RIP.
Notice that in the former dump there is a (DF), but not in the latter.
What could that mean?
Also the id from the classic app is always a pretty low number, but from
the carbon app it's rather high (I ran both apps several times).
So it seems the packets are different, and the RIP doesn't want to answer
the Carbon app. Ideas?
Here's a code snippet of the UDP broadcast (remember, with some glue to
OpenTransport, those aren't native sockets):
>
for (int i=0; i<NO_OF_TRYS; i++) {
>
ret = sendto(s, UDP_SEARCH_QUESTION.TextPtr(),
>
UDP_SEARCH_QUESTION.Length(), 0,
>
(struct sockaddr *)& server, sizeof(server));
>
if (ret != UDP_SEARCH_QUESTION.Length()) {
>
// error we do not need to deal with
>
}
>
OTIdle();
>
for (;1 == select(s+1, &readfds, NULL, NULL, &timeout);) {
>
ret = recvfrom(s, inputBuffer, BUFFER_LENGTH, 0,
>
(sockaddr *) &incomingData, &lengthOfIncomingData);
I am ignoring the error code after sendto, but hey, it's (intentionally)
UDP and doesn't really matter here... But when debugging the ret val was
always OK.
There are quite some calls to OTIdle() in that code because, well,
without them it didn't work at all (MacOS 9 and earlyer had cooperative
multitasking).
Marc Stibane
Fesh! email@hidden
Kurf|rstenstr. 154 tel +49-30-3990 2690
10785 Berlin, Germany mobil +49-173-6522 422
In a world without walls and fences,
who needs windows and gates?
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.