<Yorlik>
Seems it doesn't like my tuple. So I geuss a tuple doesn't have a default serializer?
<K-ballo>
*your* tuple?
<Yorlik>
My pong message has a tuple of two uint64_t as payload
<Yorlik>
It's my tuple, because I wrote it down ! :P
<K-ballo>
but `std::tuple`, not `your::tuple`, right?
<Yorlik>
Yes - I'm using a std::tuple
<K-ballo>
let me check which header is needed for serializing that.. hpx own's tuple works out of the box
<Yorlik>
No custom impl
<Yorlik>
I really would like not to use custom HPX datastructures in my net messages, to have a choice to change the serializer later if necessary.
<Yorlik>
Like some HPX specific tuple
<K-ballo>
looks like we don't have support for sreializing std::tuple
<K-ballo>
just hpx::util::tuple
<K-ballo>
why would you change the serializer later? and how does using std::* give you that?
<Yorlik>
Allright. I'll make a custom serializable payload then.
<K-ballo>
if you were using your::* tuple then sure, you'd be in complete control of serialization, but std::* ones we own too
<Yorlik>
I just don't know. But I'm at such an early stage, I don't want to lock myself in
<K-ballo>
a real struct is always a win over tuple<>
<Yorlik>
What's so bad about tuples?
<Yorlik>
Do you serialize any container types or just structs intrusively?
<K-ballo>
mh? rephrase?
<Yorlik>
Which types are supported by HX to serialize out of the box?
<Yorlik>
<<P
<Yorlik>
So - came up with this quick and dirty struct:
<Yorlik>
template <typename T, typename U = T>
<Yorlik>
struct cs_pair {
<Yorlik>
T first;
<Yorlik>
U second;
<Yorlik>
cs_pair( ) = default;
<Yorlik>
cs_pair( T f, U s )
<Yorlik>
: first { f }
<Yorlik>
, second { s } {
<Yorlik>
}
<Yorlik>
template <class Archive>
<Yorlik>
void serialize( Archive& ar, const unsigned int version = 1 ) {
<Yorlik>
ar& first;
<Yorlik>
ar& second;
<Yorlik>
}
<Yorlik>
};
<Yorlik>
---
<K-ballo>
fundamental types, empty types, hpx own types, and some std and boost types (given the right extra #include)
<Yorlik>
Do docs exist for this or do I have to dig sources?
<K-ballo>
and I believe there was even an attempt to automatically serialize aggregates via structured bindings, but if there is you should not relay on that
<K-ballo>
docs for what, especifically?
<Yorlik>
I'll just come up with some custom serializables for my messages
<Yorlik>
Docs for the serialization types supported and how to use them.
<Yorlik>
Working on a cs_vector now using split serialization
<K-ballo>
I doubt it, we used to use boost.serialization and it's unlikely we ported their docs
<K-ballo>
I wouldn't recommend including hpx.hpp to begin with
<K-ballo>
I don't know whether it is expected to include those adaptor headers too or not
<Yorlik>
It helps me to get stuff up faster. But I'd love to have a type/header crossreference ....
<K-ballo>
you and me both :P
<Yorlik>
I really don't want to dig into doxygen over and over again
<Yorlik>
Without the doxygen docs I'*d be horribly lost anyways
<K-ballo>
for serialization support, specifically, the unit tests are the best place to look at
<Yorlik>
Allright.
<K-ballo>
if something is supported there's a test for it there
<Yorlik>
Seemsd I need to start some more recipes in my custom doc
<Yorlik>
Still have to prepare a proper pull request for the stuff I already made.
<Yorlik>
It's so tedious - lol
<Yorlik>
Allright - seems to work with std::array now. It starts being fun. Now - how would I do the compression part?
<Yorlik>
Though we might just do compression on the Datagram layer when we batch messages.
<Yorlik>
Same with encryption
<Yorlik>
it's not yet decided.
<K-ballo>
have you looked at the compression plugin yet? is that insufficient?
<Yorlik>
No. It's all totally new to me.
<Yorlik>
It doesn't have to compress to heavily - speed is more important.
<Yorlik>
But I think I'll just push that back for now
<K-ballo>
there's per-parcel compression support for bzip2, zlib, and snappy
<Yorlik>
The networking I am currently doing will be replace by our customlibrary anyways - so staying at the message level for now is good
<K-ballo>
you just need to enable it
<Yorlik>
We are doing a custom UDP library, which hopefully will be near finished end of the year
<Yorlik>
It's all about communication with the Unreal Engine.
<Yorlik>
Though - the more I think about it - it might make sense to use HPX here too.
<Yorlik>
But there is a library boundary.
<Yorlik>
Still it could make sense to have hpx sitting in that library and use it to call into UnrealEngine with a thin translation layer
<Yorlik>
My original idea was to just map messages to function calls in the adapter
<Yorlik>
The client is a dll which is independent of Unreal
<Yorlik>
And there is a thin adapter doing the translation - such we could easily use a different client later on if we wish to.
<Yorlik>
I need to think about this more a bit later. For now I just want to get something up and running. The main internal interface will be messages anyways, but it might just happen that I succumb to HPXifying everything.
<Yorlik>
To fully use HPX for client/server we'd need things like UDP transport, unreliable actions, state snapshots and delta updates. That's all very gaming specific. My fear is if I'd try to model these things as extensions to HPX it might just be a rabbithole sucking up way too much of my resources.
<Yorlik>
Game networking is really very different in many ways.
<K-ballo>
"game <anything> is really very different" is something I've never ever heard before
<Yorlik>
Especially it is not precise, but just trying give clients a good enough, believable approximation of the game state. If you look at multiplayer games precisely, every client is actually playing a different game and everything is made to have everyone believe they are playing the same game.
<Yorlik>
Ofc the underlying super low level stuff is always the same.
<Yorlik>
But it diverts quickly.
<heller>
UDP parcelport would be kinda cool ;)
<Yorlik>
heller: If you can afford the time at som point I'd like to chat with you about possibilities here. I am not sure there are real synergies to exploit for us or not. But what I could imagine would be a nice interface in the end.
<heller>
Yorlik: if you ask a person working in a specific domain, that person will always say something like "my domain is really very different in many ways"
<heller>
our stance is to being general purpose enough to allow to be used in that domain ;)
<Yorlik>
It's complicated. But that's something for voice chat. The question for me, and my concern is, that it might be quite a rabbit hole.
<Yorlik>
But ofc - I'm opene for exploring the possibilities.
hkaiser has joined #ste||ar
<Yorlik>
(away
<Yorlik>
woops - lunchtime
nikunj has joined #ste||ar
nikun__ has quit [Ping timeout: 250 seconds]
<Yorlik>
Why does this abort()?
<Yorlik>
shared_session->bytes_received is clearly below 128
<Yorlik>
I think I need to properly understand hpx input archives
<Yorlik>
I think it wants a chunk: input_archive (Container &buffer, std::size_t inbound_data_size=0, const std::vector< serialization_chunk > *chunks=nullptr)
<hkaiser>
yorlik: it's more a matter of how to use std::vector
<Yorlik>
So - what is wrong?
<hkaiser>
why do you need to directly use an archive, btw?
<Yorlik>
Because I am sending structs with UDP
<Yorlik>
HPX is just ma serializer here
<hkaiser>
if you reserve(128) that means that you can potentially store at least 128 elements without reallocation, it does not mean that your vector has 128 (default constructed) elements
<Yorlik>
Th data arrives, but now I am struggleing with the desrialization
<hkaiser>
so capacity() == 128, but size() == 0, still
<Yorlik>
I am not really sure about the inner workings here. Ijust wanted tomake sure i have a buffer of 128 at least
<hkaiser>
use resize instead of reserve
<Yorlik>
Would I have to place a default constructed struct in there instead?
<Yorlik>
I think I'm missing a lot here.
<Yorlik>
What I have so far is an asio buffer holding my serialized data
<hkaiser>
there is an example/test demonstrating zero-copy serialization, if that's what you're after
<Yorlik>
OK - I'll check that
<Yorlik>
But in the moment its about deserializing