• 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: The possible reasons for SOCK_DGRAM packet loss in PF_LOCAL domain
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The possible reasons for SOCK_DGRAM packet loss in PF_LOCAL domain


  • Subject: Re: The possible reasons for SOCK_DGRAM packet loss in PF_LOCAL domain
  • From: Vincent Lubet <email@hidden>
  • Date: Thu, 6 Jan 2011 21:08:05 -0800

It's most likely be the receive socket buffer is too small for the sender rate. Try to increase the receive socket buffer with the socket option SO_RCVBUF

Vincent


On Jan 6, 2011, at 7:22 PM, eveningnick eveningnick <email@hidden> wrote:

> Paul i ran into a problem that my app doesnt work as it was supposed
> to work. So i am wondering if its any kind of memory leak or it might
> be "UDP-problem".
>
> My app is built this way:
> one process sends data, another process retrieves it in a forever
> kqueue-retrieval loop:
>
> for(;;) {
>   struct kevent myevent;
>   int events_received v= kevent(...&myevent...);
>   if(myevent.ident=dgram_serversocket_fd && myevent.filter == EVFILT_READ) {
>        printf("There's data available to read\n");
>        recvfrom(dgram_serversocket_fd, ....);
>        printf("packet received\n");
>   }
> }
>
> Sending process blocks on sendto, while receiving process blocks on recvfrom.
> it all works fine, as long as receiver gets the message. But sometimes
> under certain circumstances receiver doesnt get the message, while the
> sender remains blocked on its "sendto" - this sendto doesnt even
> return an error, it just blocks.
> sendto is blocked, while my "forever" loop on the receiver's side
> continues to loop processing 1-second timer's ticks (i added it just
> to test).
>
> Somewhere before "sendto" i may add "NSLog("test")", and then way it
> magically begins to work, sendto sends data and the error vanishes. I
> should consider myself to be lucky that I cought this error and not my
> users.
>
> I am just wondering what should i search for - a memory leak or should
> i say "it's unreliable SOCK_DGRAM, let's switch to either SOCK_STREAM
> (which is not very appropriate because of the specific of my task - i
> dont want these TCP-like connects/closes) or something else like Mach
> ports".
>
> Maybe someone had faced with that before, or has any ideas?
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Macnetworkprog mailing list      (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Follow-Ups:
    • Re: The possible reasons for SOCK_DGRAM packet loss in PF_LOCAL domain
      • From: eveningnick eveningnick <email@hidden>
References: 
 >The possible reasons for SOCK_DGRAM packet loss in PF_LOCAL domain (From: eveningnick eveningnick <email@hidden>)
 >Re: The possible reasons for SOCK_DGRAM packet loss in PF_LOCAL domain (From: Paul M <email@hidden>)
 >Re: The possible reasons for SOCK_DGRAM packet loss in PF_LOCAL domain (From: eveningnick eveningnick <email@hidden>)

  • Prev by Date: Re: The possible reasons for SOCK_DGRAM packet loss in PF_LOCAL domain
  • Next by Date: Re: The possible reasons for SOCK_DGRAM packet loss in PF_LOCAL domain
  • Previous by thread: Re: The possible reasons for SOCK_DGRAM packet loss in PF_LOCAL domain
  • Next by thread: Re: The possible reasons for SOCK_DGRAM packet loss in PF_LOCAL domain
  • Index(es):
    • Date
    • Thread