qstat-devx — Discussion between QStat developers

[QStat-devx] qstat 2.6 released

[Ludwig N. <l-...@us...>]

Hi,

I've created the 2.6 tarball and uploaded it to sourceforge. The CVS
tag is qstat_2_6_release. Who is doing the website? Is there a list
of people we need to send an announcement to?

cu
Ludwig

-- 
(o_     Ludwig Nussel
//\   ICQ:     52166811
V_/_  PGP Key: FF8135CE

Re: [QStat-devx] release?

[Steven H. <ki...@mu...>]

----- Original Message ----- 
From: "Ludwig Nussel" 

> That cannot be the case otherwise you wouldn't even have printf. The
> variadic macro might be gcc specific but variadic functions aren't.
> You lose the file, line and function tags without the macro of
> course but apart from that I would expect it to work.

Indeed sorry was clear I did in fact mean in macros.

>> I committed a version that works for both gcc and ms vc friday night
>> although it does just disable debugging for win32 totally as the
>> comment said. Didn't have time to investigate an alternative sorry
> 
> That's fine. No problem as long as it works on Linux :-)

:)

> issues warnings like that:
> qstat.c:5936: warning: left-hand operand of comma expression has no effect
> if you use '#define debug 0 &&'.

Strange never got that. If u can just check the current version doesn't,
shouldn't as its in a win32 ifdef.

    Steve / K


================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137
or return the E.mail to pos...@mu....

Re: [QStat-devx] release?

[Ludwig N. <l-...@us...>]

Steven Hartland wrote:
> No u cant use arbitrary parameter numbers even though its in
> the c89 standard MS hasn't adopted it yet.

That cannot be the case otherwise you wouldn't even have printf. The
variadic macro might be gcc specific but variadic functions aren't.
You lose the file, line and function tags without the macro of
course but apart from that I would expect it to work.

> I committed a version that works for both gcc and ms vc friday night
> although it does just disable debugging for win32 totally as the
> comment said. Didn't have time to investigate an alternative sorry

That's fine. No problem as long as it works on Linux :-)

> although I suspect its not possible to fix without something silly like
> debug(X) _debug( a, b, c, X);
> and altering the calls to:
> debug( ( z, x, z ) );
> which may then work but not sure.
> Interestingly I never got a warning with gcc at all which version
> you using? Ok under both the following here:
> gcc version 2.95.4
> gcc version 3.3.3

gcc (GCC) 3.3.3 (SuSE Linux)

issues warnings like that:

qstat.c:5936: warning: left-hand operand of comma expression has no effect

if you use '#define debug 0 &&'.

cu
Ludwig

-- 
(o_     Ludwig Nussel
//\   ICQ:     52166811
V_/_  PGP Key: FF8135CE

Re: [QStat-devx] release?

[Ludwig N. <l-...@us...>]

Steven Hartland wrote:
> Seems good. Pretty sure that ut2k3 / ut2k4 querying is also new.

I was also surprised but 2.5c back in 2002 had ut2k3 support
according to CHANGES.txt.

> flags definately need updating. I suggest we change from fixed output
> to using dynamic output based on the protocol definitions for the
> game type flags.

I don't understand what you mean but lets release 2.6 first.

> Did I miss Steve J's mail as I cant seem to find the mail containing
> your quote there Ludwig?

Use a sane MUA :-)
http://sourceforge.net/mailarchive/forum.php?thread_id=5322911&forum_id=36945

cu
Ludwig

-- 
(o_     Ludwig Nussel
//\   ICQ:     52166811
V_/_  PGP Key: FF8135CE

Re: [QStat-devx] release?

[Steven H. <ki...@mu...>]

Seems good. Pretty sure that ut2k3 / ut2k4 querying is also new.
flags definately need updating. I suggest we change from fixed output
to using dynamic output based on the protocol definitions for the
game type flags.

Did I miss Steve J's mail as I cant seem to find the mail containing
your quote there Ludwig?

    Steve / K
----- Original Message ----- 
From: "Ludwig Nussel"

Steve Jankowski wrote:
> We need to update the docs and CHANGES.txt files.  This will require a review
> of all the diffs between the last release and this one.  All new options,
> flags, template variables and new game support need to be documented.
> 
> Any volunteers?  :-)
> 
> The last time I did this, I ran a unified context diff and printed it 2-up. 
> Then I did a visual scan to see what caught my eye.  It's tedious, but goes
> pretty quick.



================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137
or return the E.mail to pos...@mu....

Re: [QStat-devx] release?

[Steven H. <ki...@mu...>]

No u cant use arbitrary parameter numbers even though its in
the c89 standard MS hasn't adopted it yet.
I committed a version that works for both gcc and ms vc friday night
although it does just disable debugging for win32 totally as the
comment said. Didn't have time to investigate an alternative sorry
although I suspect its not possible to fix without something silly like
debug(X) _debug( a, b, c, X);
and altering the calls to:
debug( ( z, x, z ) );
which may then work but not sure.
Interestingly I never got a warning with gcc at all which version
you using? Ok under both the following here:
gcc version 2.95.4
gcc version 3.3.3

    Steve / K
----- Original Message ----- 
From: "Ludwig Nussel" 

> Steven Hartland wrote:
>> Don't think it does but will check when I get home, didn't like the "..."
>> syntax.
> 
> I don't understand why 'static inline void debug(int level, const
> char* fmt, ...) { return; };' shouldn't work. According to a book I
> have this is C89 (except for inline). What's the error if you
> compile this on windows? Does it work if you remove 'inline'?



================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137
or return the E.mail to pos...@mu....

Re: [QStat-devx] release?

[Ludwig N. <l-...@us...>]

Steve Jankowski wrote:
> We need to update the docs and CHANGES.txt files.  This will require a =
review
> of all the diffs between the last release and this one.  All new option=
s,
> flags, template variables and new game support need to be documented.
>=20
> Any volunteers?  :-)
>=20
> The last time I did this, I ran a unified context diff and printed it 2=
-up.=20
> Then I did a visual scan to see what caught my eye.  It's tedious, but =
goes
> pretty quick.

Proposal:

------------8<-------------
QStat version 2.6

** UPDATED for 2.6 **
Aug 15, 2004

Summary of New Features
-----------------------
new protocols:
   All Seeing Eye [-eye]
   Ravenshield [-rvs]
   Savage [-sas]
   FarCry [-fcs]
   Jedi Knight: Jedi Academy [-jk3m, -jk3s]
   Gamespy2 [-gs2]
   Steam master [-stm]
   Doom3 [-dm3s, -dm3s]
   Half-Life 2 [-hl2s] (experimental)

add option -hsn to display server names in hex [no docs]
add "servers/sec" to -progress output
add -mdelim parameter to specify the multi value delimiter ( default '|' =
)
add \final\\ to end of gamespy master request
add UT2K4 colored name parsing
add UT2 XMP colored name parsing
add SOF coloring of server names

Fixes
-----
fix custom q3 master query for masters created via qstat.cfg
fix gamespy protocol to better handle Halo and BF1942
fix for multi value fields in UT2003 e.g. Mutators.
fix XML escaping bugs

New template variables
----------------------
$SCORE    player score

Thanks
------
Timothee Besset from id Software for providing Doom3 protocol information
Alexander Sch=E4fer for fixing version and password field for Ravenshield
and of course everyone else who provided feedback and bug reports

-
Steve Jankowski
Steven Hartland
Ludwig Nussel


------------>8-------------


cu
Ludwig

--=20
(o_     Ludwig Nussel
//\   ICQ:     52166811
V_/_  PGP Key: FF8135CE

Re: [QStat-devx] release?

[Ludwig N. <l-...@us...>]

Steven Hartland wrote:
> Don't think it does but will check when I get home, didn't like the "..."
> syntax.

I don't understand why 'static inline void debug(int level, const
char* fmt, ...) { return; };' shouldn't work. According to a book I
have this is C89 (except for inline). What's the error if you
compile this on windows? Does it work if you remove 'inline'?

cu
Ludwig

-- 
(o_     Ludwig Nussel
//\   ICQ:     52166811
V_/_  PGP Key: FF8135CE

Re: [QStat-devx] release?

[Steve J. <ste...@ya...>]

We need to update the docs and CHANGES.txt files.  This will require a review
of all the diffs between the last release and this one.  All new options,
flags, template variables and new game support need to be documented.

Any volunteers?  :-)

The last time I did this, I ran a unified context diff and printed it 2-up. 
Then I did a visual scan to see what caught my eye.  It's tedious, but goes
pretty quick.

Steve

--- Steven Hartland <ki...@mu...> wrote:

> Don't think it does but will check when I get home, didn't like the "..."
> syntax.
> Don't release 2.6 as yet. I'm in the middle of implementing HL2 support.
> 
> Will get that finished off tonight. I've already posted a 2.5d beta 2 the
> other
> day for windows users.
> 
>     Steve / K
> ----- Original Message ----- 
> From: "Ludwig Nussel"
> 
> > Hi,
> > 
> > Any objections to releasing 2.6? If not I'll just do it together
> > with XQF 1.0.
> > 
> > Steve (H.): I've replaced the '#define debug 0 &&' (causes gcc
> > warnings) with 
> > 
> > #  ifdef _WIN32
> >      static inline void debug(int level, const char* fmt, ...) { return; };
> > #  else
> > #    define debug(...)
> > #  endif
> > 
> > Does that work on windows?
> 
> 
> 
> ================================================
> This e.mail is private and confidential between Multiplay (UK) Ltd. and the
> person or entity to whom it is addressed. In the event of misdirection, the
> recipient is prohibited from using, copying, printing or otherwise
> disseminating it or any information contained in it. 
> 
> In the event of misdirection, illegible or incomplete transmission please
> telephone (023) 8024 3137
> or return the E.mail to pos...@mu....
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> QStat-devx mailing list
> QSt...@li...
> https://lists.sourceforge.net/lists/listinfo/qstat-devx
> 

Re: [QStat-devx] release?

[Steven H. <ki...@mu...>]

Don't think it does but will check when I get home, didn't like the "..."
syntax.
Don't release 2.6 as yet. I'm in the middle of implementing HL2 support.

Will get that finished off tonight. I've already posted a 2.5d beta 2 the other
day for windows users.

    Steve / K
----- Original Message ----- 
From: "Ludwig Nussel"

> Hi,
> 
> Any objections to releasing 2.6? If not I'll just do it together
> with XQF 1.0.
> 
> Steve (H.): I've replaced the '#define debug 0 &&' (causes gcc
> warnings) with 
> 
> #  ifdef _WIN32
>      static inline void debug(int level, const char* fmt, ...) { return; };
> #  else
> #    define debug(...)
> #  endif
> 
> Does that work on windows?



================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137
or return the E.mail to pos...@mu....

[QStat-devx] release?

[Ludwig N. <l-...@us...>]

Hi,

Any objections to releasing 2.6? If not I'll just do it together
with XQF 1.0.

Steve (H.): I've replaced the '#define debug 0 &&' (causes gcc
warnings) with 

#  ifdef _WIN32
     static inline void debug(int level, const char* fmt, ...) { return; };
#  else
#    define debug(...)
#  endif

Does that work on windows?

cu
Ludwig

-- 
(o_     Ludwig Nussel
//\   ICQ:     52166811
V_/_  PGP Key: FF8135CE

[QStat-devx] Fwd: HL2 protocol

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

Some help on the HL2 protocol


--- Morten Striboldt <mor...@bo...> wrote:

> Subject: HL2 protocol
> Date: Thu, 12 Aug 2004 18:01:12 +0200
> From: "Morten Striboldt" <mor...@bo...>
> To: <st...@qs...>
> 
> Hi Steve,
> 
> I just noticed that you only have normal status query in the HL2 qstat
> protocol. You can get players information with:
> 
> "\xff\xff\xff\xff\x55"
> 
> And rules :
> "\xff\xff\xff\xff\x56"
> 
> 
> Best Regards
> Morten Striboldt
> http://boomtown.net
> 

Re: [QStat-devx] qstat debug message causing mess of cron jobs

[Ludwig N. <l-...@us...>]

Jack Perdue wrote:
> Can someone toss this line:
> 
>  fprintf( stderr, "INFO\n" ) ;
> 
> around line 5276 according to:
> 
> http://cvs.sourceforge.net/viewcvs.py/qstat/qstat2/qstat.c?r1=1.38&r2=1.39
> 
> It is causing our cron jobs (previously working fine)
> to generate output (every five minutes) and send us an

Fixed.

cu
Ludwig

-- 
(o_     Ludwig Nussel
//\   ICQ:     52166811
V_/_  PGP Key: FF8135CE

[QStat-devx] qstat debug message causing mess of cron jobs

[Jack P. <j-p...@ta...>]

Can someone toss this line:

 fprintf( stderr, "INFO\n" ) ;

around line 5276 according to:

http://cvs.sourceforge.net/viewcvs.py/qstat/qstat2/qstat.c?r1=1.38&r2=1.39

It is causing our cron jobs (previously working fine)
to generate output (every five minutes) and send us an
email when updating this page:

http://www.nd80usa.net/qstat-html/

Just a thought.

jack (a.k.a. SiliconSlick)
j-p...@ta...
ss...@si...

Re: [QStat-devx] Re: qstat.c bad merges?

[Steven H. <ki...@mu...>]

----- Original Message ----- 
From: "Steve Jankowski"

> On a different topic; indenting and C code formating.  Looks like your
> editor is randomly reformating parts of qstat.c.  I'm not a code style
> fascist, but changing { } placement makes it harder to figure out the
> functional part of a check-in.  For an existing function or family
> of functions, please do not make code formating changes.

Ah yes indeed it does ( work requirement ) will try and remember to
turn it off when doing qstat stuff :)

    Steve / K


================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137
or return the E.mail to pos...@mu....

Re: [QStat-devx] Re: qstat.c bad merges?

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

Looks like Ludwig checked in that change.  


Revision 1.36 
Sat Jun 19 16:30:00 2004 UTC (2 weeks, 2 days ago) by l-n 
Changes since 1.35: +19 -33 lines 
Diff to previous 1.35 
fix custom q3 master query for masters created via qstat.cfg


On a different topic; indenting and C code formating.  Looks like your
editor is randomly reformating parts of qstat.c.  I'm not a code style
fascist, but changing { } placement makes it harder to figure out the
functional part of a check-in.  For an existing function or family
of functions, please do not make code formating changes.

Steve


--- Steven Hartland <ki...@mu...> wrote:
> Looking more closely it seems intentional but there's no
> comment in the log to indicate is its so just checking.
> 
>     Steve / K
> ----- Original Message ----- 
> From: "Steven Hartland" <ki...@mu...>
> To: <qst...@li...>
> Sent: Saturday, July 03, 2004 9:16 PM
> Subject: qstat.c bad merges?
> 
> 
> > There seems to be a number of fixes gone missing in the latest
> > version is this intentional or just a bad merge?
> > The main affected function I can see is:
> > send_qwmaster_request_packet
> > 
> >     Steve / K
> 

[QStat-devx] Re: qstat.c bad merges?

[Steven H. <ki...@mu...>]

Looking more closely it seems intentional but there's no
comment in the log to indicate is its so just checking.

    Steve / K
----- Original Message ----- 
From: "Steven Hartland" <ki...@mu...>
To: <qst...@li...>
Sent: Saturday, July 03, 2004 9:16 PM
Subject: qstat.c bad merges?


> There seems to be a number of fixes gone missing in the latest
> version is this intentional or just a bad merge?
> The main affected function I can see is:
> send_qwmaster_request_packet
> 
>     Steve / K


================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137
or return the E.mail to pos...@mu....

[QStat-devx] qstat.c bad merges?

[Steven H. <ki...@mu...>]

There seems to be a number of fixes gone missing in the latest
version is this intentional or just a bad merge?
The main affected function I can see is:
send_qwmaster_request_packet

    Steve / K


================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137
or return the E.mail to pos...@mu....

Re: [QStat-devx] CVS playing up?

[Ludwig N. <l-...@us...>]

Steven Hartland wrote:
> YEp its just lost the changes that Ludwig did :(
> 
> Ludwig you'll need to add your latest changes in
> again when it comes back up down atm.

Which changes do you mean? I don't miss any.

cu
Ludwig

-- 
(o_     Ludwig Nussel
//\   ICQ:     52166811
V_/_  PGP Key: FF8135CE

Re: [QStat-devx] CVS playing up?

[Steven H. <ki...@mu...>]

YEp its just lost the changes that Ludwig did :(

Ludwig you'll need to add your latest changes in
again when it comes back up down atm.

    Steve / K

----- Original Message ----- 
From: "Steve Jankowski" <ste...@ya...>
To: <qst...@li...>
Sent: Friday, January 23, 2004 7:37 AM
Subject: Re: [QStat-devx] CVS playing up?


> Dunno, I'll check it tomorrow from work.
> 
> Steve
> 
> --- Steven Hartland <ki...@mu...> wrote:
> > I cant seem to perswade CVS to update correctly.
> > Its saying it all done but the version numbers are all
> > out compared with the web CVS. Even tried deleting
> > all and checking back out.
> > Anyone else seeing this?
> > 
> >     Steve / K
> > 
> > ================================================
> > This e.mail is private and confidential between Multiplay (UK) Ltd. and the
> > person or entity to whom it is addressed. In the event of misdirection, the
> > recipient is prohibited from using, copying, printing or otherwise
> > disseminating it or any information contained in it. 
> > 
> > In the event of misdirection, illegible or incomplete transmission please
> > telephone (023) 8024 3137
> > or return the E.mail to pos...@mu....
> > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > The SF.Net email is sponsored by EclipseCon 2004
> > Premiere Conference on Open Tools Development and Integration
> > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> > http://www.eclipsecon.org/osdn
> > _______________________________________________
> > QStat-devx mailing list
> > QSt...@li...
> > https://lists.sourceforge.net/lists/listinfo/qstat-devx
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> QStat-devx mailing list
> QSt...@li...
> https://lists.sourceforge.net/lists/listinfo/qstat-devx
> 
> 

================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137
or return the E.mail to pos...@mu....

Re: [QStat-devx] CVS playing up?

[Steve J. <ste...@ya...>]

Dunno, I'll check it tomorrow from work.

Steve

--- Steven Hartland <ki...@mu...> wrote:
> I cant seem to perswade CVS to update correctly.
> Its saying it all done but the version numbers are all
> out compared with the web CVS. Even tried deleting
> all and checking back out.
> Anyone else seeing this?
> 
>     Steve / K
> 
> ================================================
> This e.mail is private and confidential between Multiplay (UK) Ltd. and the
> person or entity to whom it is addressed. In the event of misdirection, the
> recipient is prohibited from using, copying, printing or otherwise
> disseminating it or any information contained in it. 
> 
> In the event of misdirection, illegible or incomplete transmission please
> telephone (023) 8024 3137
> or return the E.mail to pos...@mu....
> 
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> QStat-devx mailing list
> QSt...@li...
> https://lists.sourceforge.net/lists/listinfo/qstat-devx

[QStat-devx] CVS playing up?

[Steven H. <ki...@mu...>]

I cant seem to perswade CVS to update correctly.
Its saying it all done but the version numbers are all
out compared with the web CVS. Even tried deleting
all and checking back out.
Anyone else seeing this?

    Steve / K

================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137
or return the E.mail to pos...@mu....

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

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

[Ludwig N. <l-...@us...>]

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.

Additional functions for state management might be added if needed,
e.g.:

void qs_postpone_response(QSQueryResponse*, struct sockaddr_storage*);

QSQueryResponse* qs_recall_postponed_response(struct sockaddr_storage**);

cu
Ludwig

-- 
(o_     Ludwig Nussel
//\   ICQ:     52166811
V_/_  PGP Key: FF8135CE

Re: [QStat-devx] Change of PacketFunc definition?

[Steve J. <ste...@ya...>]

--- Ludwig Nussel <l-...@us...> wrote:
> Steven Hartland wrote:
> > To prevent issues like:
> > qstat.h:895: warning: initialization from incompatible pointer type
> > 
> > I propose we change the definition of PacketFunc from:
> > typedef void (*PacketFunc)( struct qserver *, char *rawpkt, int pktlen);
> > to:
> > typedef int (*PacketFunc)( struct qserver *, char *rawpkt, int pktlen);
> 
> What's the return value of deal_with_halflife_packet good for? It
> doesn't seem to be used.
> 
> cu
> Ludwig
> 

Looks like a good idea, Steven.

I just looked through the code, and I did some wierd stuff for HL
when implementing the packet combiner.  HL is the only one that
returns int.  (see combine_packets())

So what are you going to return for the rest of the PacketFuncs?
I guess you could just ignore the return for all cases except HL.

Steve