Re: OpenTransport behaviour under X
Re: OpenTransport behaviour under X
- Subject: Re: OpenTransport behaviour under X
- From: Mike Miller <email@hidden>
- Date: Tue, 28 Oct 2003 23:40:15 -0700
The basic behavior of OT remains the same, the internal timing is somewhat
different. I'm not 100% sure but I think OT on OSX runs it's own even loop
and uses this to post events. In OS9 events are posted at interrupt time
(notifiers are called at this level at any rate). I have used OT quite a bit
and have seen very different event timing between OS9 and OSX on the same
machine especially under heavy loads.
OTLook is telling you there are 8 bytes to read and you are only reading 1 -
OT should not send another T_DATA until all the data has been read. The fact
that you used to get a T_DATA in 9 but aren't doing so in 10 is not
particularly surprising since the event model is so different between 9 and
10. Using a loop in the main thread just makes the timing problem worse -
you might get the same results as you are used to if you move the OT code
into an MP Thread. Apple recommends synchronous end points in an MP thread
for best performance in OSX.
Making an additional OTRcv call can get you another byte but why not read
all 8 bytes at the same time? It makes no difference to the other end - it's
already sent the data and it's all already there.
I use OT async mostly but I'm pretty sure OTRcv won't block as long as there
is _some_ data to be read. If you're worried about OTRcv blocking you can
create a simple notifier that handles kOTSyncIdleEvent and use it to time
out a hung OTRcv.
>
From: Marc Stibane <email@hidden>
>
Date: Mon, 27 Oct 2003 14:50:25 +0100
>
To: <email@hidden>
>
Subject: Re: OpenTransport behaviour under X
>
>
Since no one answered my question (with the subject "sockets in
>
Powerplant") I repost it here under a better subject title:
>
>
> News - now it broadcasts (UDP), and gets an answer back.
>
>
>
> Under MacOS X you cannot broadcast to 255.255.255.255.
>
> You have to broadcast to your own subnet, in my case to 192.168.102.255.
>
>
>
> OK, so now I find my RIP and therefor its IP address.
>
> But then the (TCP) connect times out - no connection. There must be
>
> another gotcha in the OpenTransport glue.
>
>
Got it.
>
The code (synchronous, blocking) attempts to read 4 bytes - one after the
>
other. So it checks with OTLook whether there is data (yes), then asks
>
how much with OTCountDataBytes (8 bytes), then reads ONE byte with OTRcv,
>
and then again asks with OTLook whether there is data (no, BUMMER).
>
>
This worked under MacOS 9 - it seems under X you have to read the whole
>
buffer until you can ask again...
>
>
Is this the intended behaviour? If so where is it documented?
>
>
Do I have to change this read logic (the network code is shared with
>
MacOS 9 and Windows, and works there, so I would like to not change it if
>
possible) or is there anything I can do to get OTLook to answer T_Data
>
when there is still unread data in the buffer?
>
>
>
>
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.
_______________________________________________
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.