next »

[JWki]

Happy because I wrote a simple cross platform UDP socket abstraction that seems to work.
TCP sockets next.

Haha, I thought about doing the same, since ENet doesnt support IPv6, but not anymore (since I adopted libuv).

Maybe this could be of your interest: https://github.com/networkprotocol/reliable.io

Oh yeah it is actually something I'm looking at but it's a reliability layer on top of up
udp,and I have needs for raw udp and tcp sockets.

[Garthy]

Happy because I wrote a simple cross platform UDP socket abstraction that seems to work.
TCP sockets next.

Network abstractions are fun.

[Garthy]

Maybe this could be of your interest: https://github.com/networkprotocol/reliable.io

Nice find. I was looking at NAT traversal some years ago and getting it going for TCP at the time was a gigantic pain. UDP hole punching was much easier. Having a reliability layer over UDP would means you get something close, but that sort of thing takes time to write. I'm glad to see that someone has not only done it but made it general enough to work over any unreliable transport.

[JWki]

Yeah Glenn Fiedlers stuff is great in general. There's also https://github.com/networkprotocol/netcode.io for a full secure client/server layer, and ofc https://github.com/networkprotocol/yojimbo which is more of a complete solution for dedicated server based game protocols.


Also I just got remote logging to work in 15 lines of code - using UDP instead of TCP because I haven't written the TCP socket implementation yet, but works well enough for logging on localhost.

[Garthy]

Yeah Glenn Fiedlers stuff is great in general. There's also https://github.com/networkprotocol/netcode.io for a full secure client/server layer, and ofc https://github.com/networkprotocol/yojimbo which is more of a complete solution for dedicated server based game protocols.

Good stuff. I like the looks of netcode.io and libsodium (which it depends on). I just broke out my library notes file and start making notes furiously. Thankyou.

Also I just got remote logging to work in 15 lines of code - using UDP instead of TCP because I haven't written the TCP socket implementation yet, but works well enough for logging on localhost.

I'm guessing you won't lose too many packets to localhost in the transitional period while you write the TCP implementation.

[JWki]

Also I just got remote logging to work in 15 lines of code - using UDP instead of TCP because I haven't written the TCP socket implementation yet, but works well enough for logging on localhost.

I'm guessing you won't lose too many packets to localhost in the transitional period while you write the TCP implementation.

Yeah I don't think so either.

Also here's the whole code for a simple remote logging console:

Code:

#include <stdio.h>
#include <foundation/sockets/sockets.h>
#include <foundation/logging/logging.h>

#define REMOTE_LOGGING_PORT 8090

class SimpleFilterPolicy
{
public:
    bool Filter(fnd::logging::LogCriteria criteria)
    {
        return true;
    }
};
class SimpleFormatPolicy
{
public:
    void Format(char* buf, size_t bufSize, fnd::logging::LogCriteria criteria, const char* format, va_list args)
    {
        size_t offset = snprintf(buf, bufSize, "[%s]    ", criteria.channel.str);
        vsnprintf(buf + offset, bufSize - offset, format, args);
    }
};
class PrintfWriter
{
public:
    void Write(const char* msg)
    {
        printf("%s\n", msg);
    }
};

typedef fnd::logging::Logger<SimpleFilterPolicy, SimpleFormatPolicy, PrintfWriter> ConsoleLogger;

int main(int argc, char* argv)
{
    ConsoleLogger consoleLog;

    fnd::sockets::InitializeSocketLayer();

    fnd::sockets::UDPSocket socket;
    socket.Open(REMOTE_LOGGING_PORT);

    char buf[512];
    do {
        
        fnd::sockets::Address addr;
        size_t bytesRead = socket.Receive(&addr, buf, 512);
        if (bytesRead > 0) {
            GT_LOG_INFO("Remote Logging", "Received log from  { %d.%d.%d.%d:%d } : %s\n", addr.GetA(), addr.GetB(), addr.GetC(), addr.GetD(), addr.GetPort(), buf);
        }

    } while(true);

    socket.Close();
    fnd::sockets::ShutdownSocketLayer();
}

I guess the output can somewhat improved but I'm happy for now:

[Garthy]

Also here's the whole code for a simple remote logging console:

Cool. It's always so satisfying to complete an abstraction or framework and then be able to use it in such a way that demonstrates the elegance of its design.

I notice an interesting mix of C-style strings with C++ in there. Is this a personal style, or something else?

[Garthy]

Thank you very much Garthy, when I will start I will definitely follow you tips! The Raspberry Pi is very cheap, I knew about it, I found it particularly interesting for building a budget PC with a Linux distro under $30. And the Sparkfun tutorials seem well made, I was looking right now the "Getting Started with the Raspberry Pi Zero Wireless".

I'd recommend the Pi 3 ahead of the Zero (or Zero W) for a first Pi. Reasons:
...

Eheh, now let's make some fun! 

Good luck. SBCs are so amazing. Oh! I also recently noticed this thread:

https://forums.tigsource.com/index.php?topic=51933.0

I've already enabled notificatons on it. I'll probably end up posting there as well eventually. I was worried I was going a bit too OT with the Pi details I'd posted here, but it looks like I've got somewhere to post about the Pi where there is no danger of being OT at all.

[JWki]

Also here's the whole code for a simple remote logging console:

Cool. It's always so satisfying to complete an abstraction or framework and then be able to use it in such a way that demonstrates the elegance of its design.

I notice an interesting mix of C-style strings with C++ in there. Is this a personal style, or something else?

Personal thing I guess - I don't use std::string (or any std:: container really), actually I don't use fully dynamic strings at all. I do use fixed or capped size strings but to pass strings around I usually use char* and sometimes an explicit size when I don't want to rely on zero termination.

[Garthy]

Personal thing I guess - I don't use std::string (or any std:: container really), actually I don't use fully dynamic strings at all. I do use fixed or capped size strings but to pass strings around I usually use char* and sometimes an explicit size when I don't want to rely on zero termination.

Fair enough. I've seen the particular style used occasionally, for a range of reasons. Being able to retain printf-style formatting is a common reason.

[JWki]

Mostly performance and complexity concerns for me.
I don't need something that allocates heap memory behind my back all the time when all I want is to pass a buffer of characters around.

[Garthy]

Mostly performance and complexity concerns for me.
I don't need something that allocates heap memory behind my back all the time when all I want is to pass a buffer of characters around.

Control of heap memory is another.

[Schrompf]

You might want to have a look at C++17 std::string_view or the span type from https://github.com/microsoft/gsl for arrays.

While I'm at it: the networking in my game is still based on RakNet. Which was free and OpenSource in the past, but seems to be dead by now. The only things I ever used from it were reliable UDP and prioritized channels. So I wonder if there's maybe a better, more minimal library available? Which C/C++ networking library are all the cool kids using these days?

[JWki]

You might want to have a look at C++17 std::string_view or the span type from https://github.com/microsoft/gsl for arrays.

While I'm at it: the networking in my game is still based on RakNet. Which was free and OpenSource in the past, but seems to be dead by now. The only things I ever used from it were reliable UDP and prioritized channels. So I wonder if there's maybe a better, more minimal library available? Which C/C++ networking library are all the cool kids using these days?

https://github.com/networkprotocol/yojimbo

pretty new one, just reached production level. I think it's more minimal than raknet.

Then ofc there's enet, which I've used in the past.

Regarding string_view, yeah I'm using something similiar to that I think minus all the std:: bullshit.

Thing is, I don't need "an object that can refer to a constant contiguous sequence of char-like objects with the first element of the sequence at position zero" (which is what std::basic_string_view is) - I need a pointer to character data, and a size, and that's it. Maybe I need a version for wide characters as well. But I really don't need to pull a heavily templated header in that I don't use 90 percent of to get that.

[InfiniteStateMachine]

You might want to have a look at C++17 std::string_view or the span type from https://github.com/microsoft/gsl for arrays.

While I'm at it: the networking in my game is still based on RakNet. Which was free and OpenSource in the past, but seems to be dead by now. The only things I ever used from it were reliable UDP and prioritized channels. So I wonder if there's maybe a better, more minimal library available? Which C/C++ networking library are all the cool kids using these days?

IIRC Raknet was bought and I think it was maybe made a commercial product or something.

Edit : Raknet was purchased by occulus.



I always used ASIO for networking in c++ but it's not much more than a platform abstraction over UDP/TCP. I've been meaning to check out a library that does more stuff because networking is not my best area. Yojimbo looks promising

[Ordnas]

You might want to have a look at C++17 std::string_view or the span type from https://github.com/microsoft/gsl for arrays.

While I'm at it: the networking in my game is still based on RakNet. Which was free and OpenSource in the past, but seems to be dead by now. The only things I ever used from it were reliable UDP and prioritized channels. So I wonder if there's maybe a better, more minimal library available? Which C/C++ networking library are all the cool kids using these days?

https://github.com/networkprotocol/yojimbo

pretty new one, just reached production level. I think it's more minimal than raknet.

Then ofc there's enet, which I've used in the past.

Regarding string_view, yeah I'm using something similiar to that I think minus all the std:: bullshit.

Thing is, I don't need "an object that can refer to a constant contiguous sequence of char-like objects with the first element of the sequence at position zero" (which is what std::basic_string_view is) - I need a pointer to character data, and a size, and that's it. Maybe I need a version for wide characters as well. But I really don't need to pull a heavily templated header in that I don't use 90 percent of to get that.

If the dynamic allocation is the problem, the std::String has the Small String Optimization, that avoids the heap allocation for small strings (I think less than 15 characters).

About the performance, the std::String should be already optimized by the compiler, if you pass it by reference there is no deep copy.

Also about security I prefer std::String, it is lesser error-prone to use it, you don't need to check the things are right, buffer size, etc.

[JWki]

aaannnnnnnnnd got a working TCP implementation going - I think. At least my remote logging console now uses it and doesn't seem to break:



EDIT: This image should really have had scrolling.

Left side is the logging server, right side is the application.
The connection output in the first three lines is actually netcode.io related. Note how logging output from the TCP logger itself (tagged with the corresponding tag) isn't sent over the network because well that'd be a never ending story.

Quite happy with how I handle the whole TCP-ness - there's actually two socket types at play here, one is the TCPListenSocket which is just used to listen for new incoming connections and produces a TCPConnectionSocket for each successful connection.
These in turn are then used to Send()/Receive(). So the server just creates a TCPListenSocket, calls Listen() on it and then polls it for new connections every tick, adds new TCPConnectionSockets to a list and calls Receive() on them every tick and it all just seems to work.
Client code is even simpler:

Code:

fnd::sockets::Address remoteAddr(127, 0, 0, 1, REMOTE_LOGGING_PORT);
while(!m_socket.IsConnected()) {
            
    GT_LOG_INFO("TCP Logger", "trying to connect to %d.%d.%d.%d:%d", remoteAddr.GetA(), remoteAddr.GetB(), remoteAddr.GetC(), remoteAddr.GetD(), remoteAddr.GetPort());
    auto res = m_socket.Connect(&remoteAddr);
    if (res) { 
        GT_LOG_INFO("TCP Logger", "Successfully connected to %d.%d.%d.%d:%d", remoteAddr.GetA(), remoteAddr.GetB(), remoteAddr.GetC(), remoteAddr.GetD(), remoteAddr.GetPort());
        break; 
    }
} 

EDITEDIT: Also, on strings: this pretty much matches my attitude towards them:
https://blog.molecular-matters.com/2011/10/28/living-without-dynamic-strings/

[InfiniteStateMachine]

 

[JWki]

Also, happy with an architectural decision I just made after a lot of thinking about it, feels right.
Specific decision undisclosed just in case I flip again.
No but seriously it feels good when you decided on doing something a certain way.

[buto]

Also, happy with an architectural decision I just made after a lot of thinking about it, feels right.
Specific decision undisclosed just in case I flip again.
No but seriously it feels good when you decided on doing something a certain way.

I think that's the best part about programming. When things just seem to work out. When something simple allows you to create a complex behavior, etc...

I'm currently trying to cherry pick parts from my old engine, trying to further simplify things. This time I want add multithreading with highly decoupled systems (rendering, physics, scene, ...). The systems will communicate only through Command-Buffers. Each frame the systems will be joined and Command-Buffers will be exchanged (swapped). Let's see how it works out. I'm cautiously optimistic (->happy).