ServerSocket defaults to only 1 simultaneous connection?

My age is really showing as I have been working on a new server project and had evidently forgotten that you MUST set the MaximumSocketsConnected value of a server socket or it defaults to just 1 :wink:

I’ve got a couple of things to say about that beyond the discussion of the possibility of early onset dementia in my brain…

First there is nothing in the documentation that says the default is just 1 connection. Unless you change the default of MaximumSocketsConnected you’re not really creating a server at all. You might as well create a single socket and just call listen and then re-listen when it closes as thats what you’ve got.

Doesn’t it kind of make calling it a serverSocket rather misleading if it defaults to not actually serving up more than one connection at a time? Isn’t that kind of the whole point of a server? Shouldn’t the default be 10 or something and not 1 connection? At the very least you should mention this in the docs.

So far I have never written an app keeping this on default.
I always set it high to 100 or so.

yes, but SOME day you’ll forget :wink: And someday someone new will try to build a server and waste a lot of time trying to figure out why it doesn’t work :wink:

@James Sentman you are not the first. There is at least one other thread here on this topic. The problem is “what is a realistic default value?” 4, 8, 100. Perhaps the default should be 0 and throw an exception when this is the case.

42 :stuck_out_tongue:

I will say that we don’t tend to create objects that, by default, cause exceptions when you just write code & hit run
So i’d doubt that a default of 0 and an exception in that case would be a good default

However the limit does seem far too low at 1

10 might be better

The default used to be 10. When did it change?

I thought so too! But going back to pervious releases of other software I can say that the default has been 1 for a long time now. I’ve just tested with the PPC version of another JSON receiver app and the error is easily reproducible even there so the default of 1 goes back to at least 2011. I’ll probably be doing a PPC maintenance release of that too shortly to fix that problem. I haven’t loaded up that version of xojo in a long time :wink:

I just randomly checked Xojo 2015r3, and the default is 10.

Are you using a subclass?

hmm… I am using a subclass… how would you implement the add socket event otherwise? I just double checked with the latest release to make sure I wasn’t crazy and the default in that is definitely 1.

Place it on the window/pasteboard. So you’re creating the socket in code?

OK, I just created one in code, and yes, the default is 1 in that case. I’ve never done it that way, so I never noticed.

why do you need a Limit or default? why xojo default to 1? is unneccearray indeed . let os does that.

If you drag and drop the Server Socket, its Minimum 2 and Maximum 10 Sockets by default. However if you create it in code then you will need to set up the defaults or else it is set to 1.

Did anyone notice that James’ original post contains the hidden msg that the DOCUMENTATION is lacking here? No one thinks to have this addressed?

I used to have a login to the online documentation and did fix those things faster than writing a comment here. But I can’t do that any more (new docs system, which appears to be independent of the old one at xojo.docs.com).

Norman, couldn’t at least you give this a thought whenever some here asks for clarifications like this? If the docs only get updated when someone writes a bug report for it, it’ll never happen, and the docs remain incomplete. Since you, Norman, are the only Xojo eng who regularly follows most conversations, you could easily spot all those questions that arise from unclear docs and simply fix the docs quickly. That should help a lot in the long run, I’d think. But you have to be willing to do that.

BTW, the CORRECT way to do this all would be to document APIs FIRST, then implement them accordingly, and fix them if they do not meet the docs, not the other way as it happens here all the time. But it’s obviously too late for that.

The OS doesn’t do that, though. It’s always the application that has to tell the OS how many sockets it wants, at least on Unix based systems. Smart apps can do this dynamically, by getting more socket connections ready when they run out of them, but it’s still the app that does this, not the OS.

I’ve updated the ServerSocket.MinimumSocketsAvailable and ServerSocket.MaximumSocketsAvailable to indicate these differences in default values.

To be clear, it is always a good idea to create a Feedback case for doc stuff just as you would for anything else. I do not necessarily read every post in every thread, but I do see every documentation Feedback case. And sometimes a doc change actually needs an engineer to do some research first to either determine what the docs should say or to figure out if there is actually a bug instead.