Hello again, sorry for my late rply (was in a short holiday) and thanks for the many enlightening remarks.
After all these ideas, I am still left without an answer to my basic question, so I will clarify.
First, I am rewriting an existing code. My original code works (fine!) with a dynamic C-style ring-buffer, off which I’m parsing and reading (again!) my messages, thus copying the data twice. Once from the CFstream into my ring-buffer, then again off the ring-buffer into another C-buffer that I pass on to some external “media engine”.
As noted by others, such code suffers some disadvantages, among which - the double-copy, multithreading isn’t easy, so there are too many NSLocks involved, and - reading large amounts of data from the stream can create a performance “hickup” as my reading and writing compete over the same thread context.
Now in reply to Jens (thanks again!) the first approach WILL work (I’m finalizing my POC) because I know the prefix will come, and if I only receive 3 bytes, I’ll wait for the next “BytesAvailable” event, read again until I have the size, then continue from there. Every time, either I have enough data to read (till end of message) or the stream will wake me up again with “bytes available”.
Finally - my real question again: Is there a specific penalty to NSStream’s method read:maxLength: ? If I call it on the average 2-3 times a message, Is this far worse than reading big bulks off the stream, then doing all my book-keeping and copying and locking? I know some networking calls are doing “a trip to the kernel” which is costly to do very frequently. Is read:maxLength: such a method?
Last, several guys mentioned GCDAsyncSocket. What is it? an open-source thing? a system API I’m not aware of?
Thanks again.
On Sep 9, 2015, at 2:07 PM, Motti Shneor < email@hidden> wrote:
I need reading messages off the stream, each prefixed by 4 bytes containing its size. I was wondering if it was advisable to first read just the size (4 bytes) then read the rest of the message, or maybe it was better to have a big buffer into which to “drain” the stream, then parse my messages off the buffer?
The first approach won’t work, because the amount of data received is unpredictable. For instance you might receive only three bytes, which isn’t enough to parse the data size. Or you might be able to read the data size, but then try to read a 100000-byte message and get only 1500 bytes of it.
The usual approach when parsing data asynchronously from a network stream is to keep a variable-size buffer of unparsed data. When data arrives, you read all of it and append it to the buffer; then you try to parse the data in the buffer. If there’s not enough to parse yet, you give up till there’s more; or if you parse some data, you remove it from the start of the buffer.
So in your case you’d first check whether the buffer has at least four bytes; if so, you look at the length, and check whether that many more bytes are available. If they are, you read the whole message and remove it from the buffer.
An NSMutableData object works well as a buffer, if you’re not too concerned about high performance. The fastest implementation is probably some sort of custom ring buffer.
—Jens
Motti Shneor, CEO, suMac LTD. Software Development for the Macintosh
Home/Office Address: 34 Emek-Ha-Ella St. Appt.1 Modiin, ISRAEL, 71723 Home/Office Tel/Fax: +972-8-9267730
Office eMail: email@hiddenMobile phone: +972-54-3136621
--- ceterum censeo microsoftiem delendam esse ---
|