Re: The possible reasons for SOCK_DGRAM packet loss in PF_LOCAL domain
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