Dear Marcus,
Thanks so much for your reply!
Your experiences on encoding on network helps me a lot!
NSOperationQueue is not a technique particularly for networking. It is an
asynchronous programming solution. Using it, developers are not required to
take care of a lot of details of threading.
Best regards,
Bing
On Thu, Jun 16, 2011 at 7:49 PM, Marcus Karlsson <m...@acc.umu.se> wrote:
>
> On Jun 16, 2011, at 12:33 PM, Bing Li wrote:
>
> > Dear Conrad, Jens, Tony, Scott, Wade and all,
> >
> > I appreciate so much for your replies. I learn a lot from the
> interactions
> > with you. Since I am new, your patience is so valuable to me!
> >
> > I just got the problem. At least, right now, there is no the leak. When
> > receiving messages, I put them into a queue. However, I forgot
> implementing
> > a dealloc for it and I also did not release it when the connection was
> > disconnected. After the bug was fixed, the leaking issue was solved.
>
> Well done.
>
> > But I still have a question. The queue is actually derived from NSArray.
> It
> > should be empty after when the connection was disconnected. Why was there
> > such a huge leak?
>
> In your snippet that you sent earlier you allocated memory in an infinite
> loop. It's not uncommon that such loops keeps going for a large number of
> iterations when things goes wrong. Even if you leak just a little bit of
> data for each iteration, the sum of leaked memory can become very big.
>
> > For the TCP issues, I planned to change my current solution. I will send
> the
> > length of the buffer first and then send the real data. I have ever done
> > that on .NET. The difference is that this time I need to exchange
> messages
> > among different OSs (Java/Linux and iOS). So XML is used. On .NET, I just
> > use its serialization technique. I am not sure if I need to consider
> little
> > endian/big endian issues? My iMac is an Intel CPU. I don't need to do
> that,
> > right? What about iPad/iPhone?
>
> It's not uncommon that network protocols have the length included somewhere
> in the beginning. But it's not a bullet-proof solution and you still have to
> handle the possibility of getting fragmented data. If you're not dealing
> with persistent connections then maybe an even simpler approach could be to
> just keep reading until he remote socket is closed.
>
> XML is already encoded so you don't need to convert it according to
> endianness. It's only when you're transmitting raw bytes directly over the
> network when you need to do that. As long as you have defined your protocol
> and how you encode and decode the transmitted data it doesn't matter which
> operating system or CPU architecture is on each end. The serialization
> you've used earlier is just one way of doing that. In the end it's just bits
> that goes over the wire, whether it's XML or your own binary format doesn't
> matter.
>
> > When implementing multi-threading, NSOperationQueue is used in my system.
> I
> > don't create threads explicitly unless in some specific cases, for
> example,
> > a streaming control thread pool.
> >
> > The major reason I intend to use sockets is that I attempt to design a
> P2P
> > communication protocol when transmitting data over the Internet. I also
> did
> > that successfully on .NET. I think a controllable socket is more flexible
> > although its programming is difficult a little bit.
>
> I'm not particularly familiar with NSOperationQueue and don't know how well
> it works for network operations. I often use the CFNetwork API:s which I
> recommend that you take a look at.
>
> > I will learn Cocoa programming continually and carefully. Thanks so much
> for
> > your help again!
> >
> > Best regards,
> > Bing
> >
> >
> >
> > On Thu, Jun 16, 2011 at 4:10 AM, Conrad Shultz <
> > con...@synthetiqsolutions.com> wrote:
> >
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> On 6/15/11 12:50 PM, Bing Li wrote:
> >>> Jens,
> >>>
> >>> Thanks so much for your suggestions!
> >>>
> >>> I wonder why it works fine according to Activity Monitor if such a huge
> >> leak
> >>> exists. The consumed memory in the Activity Monitor is stable and much
> >>> smaller unless some threads are created at a high concurrent moment.
> >> After
> >>> the threads are dead, the consumed memory becomes stable and small. I
> >> feel
> >>> weird for this.
> >>
> >> Honestly, I feel like you are not listening to the excellent responses
> >> people are giving you.
> >>
> >> 1) Activity Monitor is not a profiling tool. Don't use it as such. Use
> >> Leaks/Allocations, maybe with some heapshot analysis thrown in as I
> >> believe I mentioned a while back.
> >>
> >> 2) Analyze your code with the Clang static analyzer ("Build & Analyze").
> >> This will shake out many common memory issues (and more).
> >>
> >> 3) Recognize that posting snippets of the code that you THINK might be
> >> responsible for a leak does not mean that people on the list can
> >> actually help you find it. For example, even if you are doing
> >> everything completely properly inside a function, if that function
> >> returns some object, the calling code can still leak that object.
> >>
> >> 4) It seems as if much of your code is multi-threaded. All else being
> >> equal, this makes such problems even harder to debug. If I were having
> >> such serious issues, I would probably spend some time trying to get the
> >> task to work on the main thread and only once that is thoroughly
> >> debugged would I break it up across threads. (This won't work for every
> >> type of problem, but if it can work for you, I'd do it.)
> >>
> >> 5) As others have commented, there is substantial evidence that your
> >> code probably has issues other than memory management. If you are, for
> >> example, smashing the stack in your C code, all bets are off and you
> >> really need to fix that first.
> >>
> >> It's been so long since you first started posting that I've forgotten
> >> what you are trying to do. You are communicating in a high level format
> >> (XML), yet all your code seems to concern very low level network
> >> behaviors (opening sockets, reading bytes, et cetera). I wonder whether
> >> you are over-engineering all this. What is your goal?
> >>
> >> - --
> >> Conrad Shultz
> >>
> >> Synthetiq Solutions
> >> www.synthetiqsolutions.com
> >> -----BEGIN PGP SIGNATURE-----
> >> Version: GnuPG v1.4.7 (Darwin)
> >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> >>
> >> iD8DBQFN+RG8aOlrz5+0JdURAjRNAJ9YCKwfHbB6iICdmKARupttOoJkMQCdG5TT
> >> ZAaJuogqgVGHjKxS4sqA8pw=
> >> =RkC+
> >> -----END PGP SIGNATURE-----
> >>
>
>
>
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
