Re: [QStat-devx] draft for new query protocol and API

[Steve J. <st...@qs...>]

--- Ludwig Nussel <l-...@us...> wrote:
> Steve Jankowski wrote:
> > > > Multiple outstanding requests.  Given that a packet write is a non-
> > > > blocking operation, and a game server is likely to prioritize status
> > > > responses below actual game processing, the server could be sending
> > > > status responses to multiple destinations at the same time.  It seems
> > > > like your API can support this, but it requires the app to track the
> > > > state information.  If the app can only send 2 of 4 fragments, then it
> > > > has to save the IP, port, queryresponse, fragnr, and reslen in some
> > > > list.  The app will then need some code to occasionally run the list
> > > > to try sending more query responses.  Seems like the API should take
> > > > care of all these details.
> > > 
> > > Isn't that's too complicated? Storing all that information probably
> > > costs more CPU cycles than just calling a couple of send(). I didn't
> > > want to deal with IP Adresses, otherwise it would be necessary to
> > > support IPv4 and IPv6.
> > 
> > Supporting IPv6 is not required (and why would you?  there's no IPv6
> > games and game developers are not talking about it).
> 
> Commercial game developers maybe. Some free games, especially
> Quakeforge and Quake2 already have IPv6 support.
> 
> > A good API implements all the complicated stuff so the app doesn't
> > have to.  If the API is too "thin", that presents a barrier to
> > adoption.  That complication has to be some where.  If it's in the
> > API, then every app benefits.  If it's in the app, then every
> > app gets to make the same mistakes.
> 
> What about this interface:
> 
> QSQueryResponse* qs_prepare_response(const char* buf, size_t len);
> 
> char* qs_next_response(QSQueryResponse* response, size_t *len);
> 
> QSQueryResponse is some opaque structure to the application. The
> library might store a linked list or an array of response fragments
> inside. qs_prepare_response creates that structure. qs_next_response
> removes one fragment from the structure and returns it. If no more
> fragments are left, the structure is freed and NULL returned.

Yeah, that looks good.  I'd also add the IP and port so the app doesn't
have to maintain any data structures.  If you want to be IPv6 compatible,
then pass params like:

..., void *ip, int ipLen, unsigned short port)

Steve