• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: SecureTransport and socket I/O
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SecureTransport and socket I/O


  • Subject: Re: SecureTransport and socket I/O
  • From: Mike Kluev <email@hidden>
  • Date: Tue, 30 Sep 2003 01:25:26 +0400

On 28 Sep 2003 13:22:56 +0200, Frederick Cheung <email@hidden>
wrote:

>> On 9/27/03 11:24 AM, Larry Gerndt wrote:
>>
>>> I posted a few weeks ago about some problems I was having where SSLRead()
>>> was
>>> returning "sslProtocolErr". My socket was set for blocking mode, so in
>>> attempting to fix this problem, I switched over to non-blocking mode and
>>> copied Apples's SSLSample's SocketRead and SocketWrite code, and it worked
>>> fine. Then I switched the socket back to blocking mode and left Apple's
>>> SocketRead and SocketWrite code in place and it still worked. So I did some
>>> investigation, and found out that even in blocking mode, the socket read
>>> function can return without having read as much data as we requested,
>>> meaning
>>> you have to read again to get the rest. Apple's sample SocketRead handles
>>> this case and does the additional reads. By the way, on the first read,
>>> it's
>>> not returning -1 and EAGAIN, it's returning a positive value, indicating how
>>> many bytes it did indeed read, but that amount was not as much as I
>>> requested,
>>> so it then reads again to get the rest, and this works great.
>>>
>>> My question: I thought in blocking mode, a "read" of a socket would not
>>> return until as many bytes as requested are read. Was I wrong in this
>>> assumption?
>>
>> To answer my own question, I re-read the man page on "read", and I guess I
>> was indeed wrong, because the only time a synchronous (i.e blocking) read
>> guarantees to not return until the requested number of bytes has been read
>> is in the case of reading files which do contain that many bytes between the
>> current read point and the end of file. This was news to me and a valuable
>> lesson.
>
> The same is true for OT under X (but obviously not on 9)

Then what is the difference between "synchronous blocking" and
"synchronous non-blocking" modes? I would expect the former to
wait for as many bytes as specified and the latter to return
immediately with as many bytes as available.

Mike
_______________________________________________
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.

  • Follow-Ups:
    • Re: SecureTransport and socket I/O
      • From: Frederick Cheung <email@hidden>
  • Prev by Date: Re: Raw Ehternet Sockets on 10.1?
  • Next by Date: Re: SecureTransport and socket I/O
  • Previous by thread: Re: SecureTransport and socket I/O
  • Next by thread: Re: SecureTransport and socket I/O
  • Index(es):
    • Date
    • Thread