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 10, 2015, at 01:30, Jens Alfke <j...@mooseyard.com> wrote: > > >> On Sep 9, 2015, at 2:07 PM, Motti Shneor <su...@bezeqint.net >> <mailto:su...@bezeqint.net>> 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 Home eMail: motti.shn...@gmail.com Office eMail: su...@bezeqint.net Mobile phone: +972-54-3136621 --- ceterum censeo microsoftiem delendam esse ---
_______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/macnetworkprog/archive%40mail-archive.com This email sent to arch...@mail-archive.com
