GNOME Bugzilla – Bug 738207
Add a way to set SO_SENDBUF and SO_RECVBUF on listener (and maybe client)
Last modified: 2015-04-04 19:29:51 UTC
According to the docs, these two socket options need to be set *before* listen() or connect(). For this reason they cannot be set with g_socket_set_option after obtaining the socket from the connection. On the client it seems the workaround is to connect to the event signal, and set the option when the event is "CONNECTING". On the listener however, the only way I can see is to not use _add_address or _add_inet_port and instead manually create the socket and then use _add_socket, and this removes a large chunk of why using Listener is handy (e.g. hiding IPv4/IPv6 headaches). As far as I understand even adding a getter to get the list of listening gsockets from the listener would not do much good because once you add_inet_port etc, the socket will be created and it will start to listen right away. I can see the following possibilities: * add listener_set_send/receive_buffer_size (very ad hoc, similar in principle to listener_set_backlog, which also has to be set before starting to listen) * add a more generic listener_set_socket_option that sets the option on all the sockets that will be created by the listener * add a signal to hook into the creation of the socket before it starts to listen
Created attachment 288132 [details] [review] patch adding a signal As per irc discussion: <pbor> desrt, danw: I posted https://bugzilla.gnome.org/show_bug.cgi?id=738207 with the issue I asked about yesterday, if you have a preference I can try to work on a patch... I am leaning toward the signal since it seems more flexible and coherent with the client <danw> pbor: yeah, the GSocketClient signal has turned out to be useful for a bunch of unrelated things, so I think it would be good for GSocketListener too <pbor> danw: cool, I'll do that then The patch is still untested, just posting it for my own reference and to gather a first round of comments about names or whether the signal should have other arguments
quick thoughts: "LISTENING" is consistently misspelled with an extra "T" There should be an event before calling bind(). And I guess for completeness and consistency with GSocketClient, one after calling listen(). (so, BINDING, BOUND, LISTENING, LISTENED?) GSocketService might want additional events that GSocketListener doesn't need?
(In reply to comment #2) > "LISTENING" is consistently misspelled with an extra "T" Oups :) > There should be an event before calling bind(). And I guess for completeness > and consistency with GSocketClient, one after calling listen(). (so, BINDING, > BOUND, LISTENING, LISTENED?) > Well, I had the same doubt... and the fact that you assumed LISTENING was emitted before calling listen() and not after, confirms my choice was not good. However in your proposal BOUND and LISTENING would be emitted right after the other since there is nothing to do between. I also do not like much LISTENED since it sounds like it was listening and not it stopped. What about - emit BINDING - bind() succeeds - emit BOUND - listen() succeeds - STARTED_LISTENING > GSocketService might want additional events that GSocketListener doesn't need? I guess it could have ACCEPTING/ACCEPTED, but I did not see a use case for that since at that point you have the connection object and it is better to work with that. So I preferred to keep the event list to the minimum, we can always add more later
maybe at the end of the day we just really want a "bound" signal?
(In reply to Paolo Borelli from comment #3) > Well, I had the same doubt... and the fact that you assumed LISTENING was > emitted before calling listen() and not after, confirms my choice was not > good. > > However in your proposal BOUND and LISTENING would be emitted right after > the other since there is nothing to do between. GSocketClientEvent has pairs that are always emitted back-to-back as well (eg, RESOLVED and CONNECTING). Even though they essentially mean the same thing, the caller's logic may make more sense in terms of one of them than the other. > I also do not like much > LISTENED since it sounds like it was listening and not it stopped. I think, in the context of the other GSocketClientEvent / GSocketListenerEvent names, it's clear what it means. I think the consistent naming pattern in GSocketClientEvent is useful, and I'd like to keep that pattern here.
Created attachment 300082 [details] [review] patch
Comment on attachment 300082 [details] [review] patch >+ * @G_SOCKET_LISTENER_LISTENING: The listener is to start listening on >+ * this socket. "is ABOUT to" >+ * Since: 2.48 2.46 >+ /** >+ * GSocketListener::event: >+ * @listener: the #GSocketListener >+ * @event: the event that is occurring >+ * @socket: the #GSocket the event is occurring on >+ * >+ * Emitted when @listener's activity on @socket changes state. >+ * >+ * Since: 2.48 >+ */ Again, 2.46. Also, mention that for APIs that listen on both IPv4 and IPv6, a separate set of signals will be emitted for each, and it's undefined what order they happen in. The code looks good. Though it would look even better with a test case... :)
Created attachment 300952 [details] [review] patch Updated according to the comments and added a unit test
Pushed. Thanks for the review!