Is jobid_source only viable when doing service messages?

[ABaumher]

JobIDs seem like a nice way to map a request to a response, but internally the code here seems to use Invalid for any Client message calls and the callback procs for all responses, not just the potential requested one. (an aside, your jobid logic is cleverly obtuse). The only time i've seen it used with a valid value is in the login service calls.

From my testing, setting jobid_source on a request header is ignored in the response (the values i get back are ulong.MaxValue). Am i doing something wrong (i.e. the ClientLogin message has a field that is missing or not initialized properly)?

[voided]

You're on the right track, only certain kinds of messages support JobIds. Not sure if there's a way to tell from the outside, but we wrapped what we could around the `AsyncJob` machinery in SteamKit based off the reverse engineering of the steamclient binaries, and those had more obvious hints that something was job based. The Steamworks SDK can also clue you into what messages are job based - look for callback handling that involves `JobId_t`s

…

On Tue, Jul 18, 2023, 9:01 AM ABaumher ***@***.***> wrote: JobIDs seem like a nice way to map a request to a response, but internally the code here seems to use Invalid for any Client message calls and the callback procs for *all* responses, not just the potential requested one. (an aside, your jobid logic is cleverly obtuse). The only time i've seen it used with a valid value is in the login service calls. From my testing, setting jobid_source on a request header is ignored in the response (the values i get back are ulong.MaxValue). Am i doing something wrong (i.e. the ClientLogin message has a field that is missing or not initialized properly)? — Reply to this email directly, view it on GitHub <#1238>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASR27JKKDXJJU74G6265DDXQ2JLZANCNFSM6AAAAAA2OONJHU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ABaumher]

You're on the right track, only certain kinds of messages support JobIds.

Not the answer i was hoping for but i more or less expected that.

Is there a valid way to map a request to a response (or group of responses for messages steam likes to break up like persona state or pics product info)? Initially i thought multis would be a valid option but Steam seems to wrap every message in a multi, and occasionally groups potentially unrelated messages together. ProtoHeader also contains a message_id though i haven't seen any examples of its use.

For context, the toolkit I'm integrating with uses async calls almost exclusively. It's also python, and the implementation diverges heavily from ValvePython (which is maintained by a contributer here and i'd prefer it immensely given the opportunity). There were some callback-driven calls in the code mixed in with the async ones when i took over development, but they are not pretty and i'd very much prefer to get rid of them.

In your code you provide the option to convert an AsyncJob to a task and await it but I'm not sure how well that concept would work for messages that seem to be sent in parts.

[voided]

You've pretty much reasoned yourself into the explanation for why SteamKit seems to have 2 APIs for dealing with request/responses: callback based + the awaitable AsyncJob.

The callback model is based off the way Valve's steamclient internals handle messages (and this same model gets exposed publicly via things like the Steamworks SDK, which also expose callbacks for various operations).

I'm not really sure there's a complete way to associate non-job based responses with the original request that triggered them - this becomes even more complex for the persona state scenario as the server will send persona state messages without the client having originally requested anything.

Valve's implementation is heavily coroutine based, but some of the patterns I recall seeing many years ago are APIs like:

• BYieldingWaitForJob - "await" the completion of a job. AsyncJobs are our analogue in SteamKit
• BYieldingWaitForMessage - "await" the arrival of a particular message type, ignoring job ids. We don't have this in SteamKit, and this is primarily what you'd be looking for.

I'd say our rationale for not having an API like this is that we're not fully certain what kinds of messages can be waited on like this - persona state, for example, you couldn't model this way - but things that are concrete "one request, one response" fit better with it.

We just don't really know which messages 100% fit this pattern and so we took the safe route of exposing everything via callbacks and hoisting the responsibility to the consumer.

[ABaumher]

Makes sense.
It looks like for the majority of the messages i can expect 1:1 request/response, and use the job id where available and the message type when not as you suggest. I already process and cache server-side messages separately. The whole reason i was looking into job id was figuring out how to group multi-part messages so i knew if the cached data was "ready" but it looks like that's a whole separate issue

[ABaumher]

at risk of commenting after accepting an answer, is PICSProductInfo really a valid job_id source? Your sample asyncjob code uses it and while i'd need to tweak my code massively to not fire at the first response, that seems like a massive boon. Unfortunately, you are correct, there isn't a good way to check from the outside if there are other job_id calls, though i can trace what you wrapped in AsyncJob. afaik ProductInfo is the only AsyncJobMultiple i have seen but that's proving a bit more difficult to trace.