Search Unity

  1. Unity 6 Preview is now available. To find out what's new, have a look at our Unity 6 Preview blog post.
    Dismiss Notice
  2. Unity is excited to announce that we will be collaborating with TheXPlace for a summer game jam from June 13 - June 19. Learn more.
    Dismiss Notice

Resolved How to properly handle "server is full"

Discussion in 'Unity Transport' started by MariuszKowalczyk, Mar 26, 2023.

  1. MariuszKowalczyk


    Nov 29, 2011
    Almost always there has to be some limit of connections on the server. Currently I handle this by using Accept() and then if my array of connections is full, I disconnect the new connection and do not add it to the array.

    The problem is that this approach is generating the Connection Event on the client (probably because the Accept() function was called. I do not want the Connection Event to be called when the server is full. So I would like to avoid accepting the connection on the server, when it is full.

    I will be able to find a workaround for this, but still I would like to hear if there is a way to do what I want.

    So I need a function like: PopIncomingConnection() and only when I want to accept I would call Accept() to accept it. If I would not call Accept(), it would mean rejections and disconnection (only the disconnection event would be generated on the client).
    Last edited: Mar 26, 2023
  2. simon-lemay-unity


    Unity Technologies

    Jul 19, 2021
    Currently the recommended approach to handle connection limits is to
    connections and immediately
    them afterwards (the approach you took). We do not plan to add another way to deal with this problem at this time, but we're open to revisit this later if there's a need.

    About avoiding the
    event, currently it's unfortunately unavoidable. If you need a reliable signal for the client to know it can initialize, our recommendation is to have the server send a dedicated message for that. So instead of relying on the
    event to initialize, a client would rely on that separate message, which the server would send only if there was room for the client. This would fit better with the idea of the transport package being only a base on which users build their own solutions. We're not offering advanced connection management because the expectation is that users will build their own on top of what the transport offers.
    MariuszKowalczyk likes this.