Level 6
Globoux wrote:Very cool ! I got it working over ppp0 ! Thankfully one of my mobile isps uses real adresses for mobil users but as expected I had less luck over the router on my wired system tho I get why but i had to try .
I think Ill bridge the modem and set up a bsd router so I can do it properly . So futuristic !
Begin mini-rant.
No, it's not futuristic at all. There are relatively new sites which describe IPv4 to IPv6 migration standards and write about them like they are new and exciting, but in reality they are along the line of ten years old. We shouldn't be starting the move to IPv6 now; the migration period should be nearing its end.
End mini-rant.
Still; it's nice to see that people are starting to take the first steps towards a migration.
I mentioned my ipv6adventures to my boss and he wants me to look at making some of our applications ipv6 ready . Have you done this ? I started looking at ipv4 mapped adresses but the drawbacks scare me . Event based applications arent a problem but we have singlethread recvfrom () applications also .
All network projects I've done since a while back are IPv6 enabled, and I have IPv6:ified a few old programs as well. The extremely condensed version is:
- replace name (dns, dotted and colon represented) to binary address with getaddrinfo(3). (NetBSD's man pages has a very to-the-point example on how to use it).
- the magic of making your program AF_INET/AF_INET6-"agnostic" (it's not really, but you'll see what I mean) is in getaddrinfo().
- replace binary address to name lookups with getnameinfo(3).
- use sockaddr_storage instead of sockaddr_in (and sockaddr_in6).
As for singlethreaded/-socket applications with IPv4/6 support I'm afraid you're stuck with IPv4 mapped addresses (although they have some important caveats, if you know what you're doing and are careful, I wouldn't discard the idea of using them). But if I understand you corrently you're using an event framework for other applications? Is there any specific reason these single-socket apps can't be event:ified as well? It's not like event loops are only for large apps.
I want to stress that networking is not my strong suit; especially on the administration side of it. Feel free to ask further questions, but know that we're nearing the limits of my networking knowledge.
PatC_PSN wrote:
zinep wrote:
I want to stress that networking is not my strong suit
It's probably no worse than your capacity to post stuff in appropriate discussion forums.
I don't think there's a "Let's talk out of our arses pretending we know what we're talking about" section.
I guess GD is about as close as it gets.
Level 3
Warren_Jeeves wrote:
PatC_PSN wrote:
zinep wrote:
I want to stress that networking is not my strong suit
It's probably no worse than your capacity to post stuff in appropriate discussion forums.
I don't think there's a "Let's talk out of our arses pretending we know what we're talking about" section.
I guess GD is about as close as it gets.
That would probably turn into one of the most popular sections
Level 1
Thnx for the info it saved me lots of time !
if I read the dox right : getaddrinfo () will return a list to all suitable socket types and we need to iterate throgh the list and determine which we want to use and discard the rest ? Wont it return ipx and other strange protocols ? I guess it means we open separate sockets for the ipv6 and ipv4 sockets . This will need some rewiring ! 
We can rewrite all the apps to use event libs but i was looking for a solution which is better for my lazy nature ! 
Also the boss wants us to keep changes to a minimum .
I realised another problem with having multiple sockets . I was thinking about using a separate physical interface for a test network for ipv6. We have a udp peer based system where the nodes look up peers by localy stored name adress and call them and the peer needs the source adress and port to make a call back . I guess its not so easy as send on any socket and the network stack sorts it out?
Level 6
Globoux wrote:[---]
if I read the dox right : getaddrinfo () will return a list to all suitable socket types and we need to iterate throgh the list and determine which we want to use and discard the rest ? Wont it return ipx and other strange protocols ? I guess it means we open separate sockets for the ipv6 and ipv4 sockets . This will need some rewiring !
Well, yes, one needs to filter out the appropriate entries. You use the 'hints' to get a rough filtering, and then do your custom filtering while iterating through the result.
And yes, you will probably need to do some rewiring.
I realised another problem with having multiple sockets . I was thinking about using a separate physical interface for a test network for ipv6. We have a udp peer based system where the nodes look up peers by localy stored name adress and call them and the peer needs the source adress and port to make a call back . I guess its not so easy as send on any socket and the network stack sorts it out?
Ok, so this is getting into network stack implementation details, but it's related to the rewiring you referred to, and it's something you'll eventually need to get into (at least a little bit).
First off, read rfc4907. Pay attention to the Strong/Weak ES distinction. In essence, in a Weak ES system, you could guess that "some router/gateway, somewhere, will handle this". However, for Strong ES stacks, you need to send on the proper socket, or the stack will discard the packet. Add to the mix that there are hybrid systems as well..
This isn't something you can feature macro your way out of if you need to be portable (both on an OS and a network level). There are many solutions, but for some initial inspiration I'll mention two which are on the opposite sides of a "manual administration vs test/probe the network"-scale.
If it's feasible, you could tightly couple listener sockets and peer addresses in the applications' configurations. I'm guessing for most known-structure systems this is the easiest way to do it. But it could also be a nightmare to administrate, depending on the scale of the system, how much changes in it, and what types of administration systems are in place.
If you want/need peer addresss and listeners to be decoupled, and probing the network isn't a problem, you could use something along the line of:
enum SockState { NodeAddrUnknown, NodeAddrGuess, NodeAddrKnown };
struct _peer {
...
int sock;
enum SockState ss;
struct sockaddr_storage addr;
socklen_t addrlen;
...
};
If a node has a peer's address, it sets it to "Guess" at startup (otherwise Unknown). When you send a packet and the state is "guess", then send packet through all bound sockets (using whatever ordered/unordered method which is suitable, depending on the level of control you want).
Once a packet is received from a peer, pass the listener socket and socket address/port to whatever function/thread which processes the packet, and store the socket, port and address in the _peer structure. Then set ss to NodeAddrKnown. From this point, you know which socket, address and port to use when sending to a specific peer. (Obviously handling cases where nodes go missing by lowering the sock state, depending on cirumstances, etc).
I'm going to take a wild guess: You currently have a global "sock" somewhere which everything is sent through it? As you said, it will require some rewiring. This is why I recommend people to assume multiple interfaces with multiple networks (without a route between them) from start. Writing support for it from the beginning is trivial. Changing things afterwards can be a pain (depending on how much one has thought things through).
I somehow suspect that the first method will suit your systems better, but if you're looking for the latter, I have some relevant code should you want it.
Website ©2013 Sony Computer Entertainment Europe
All content, game titles, trade names and/or trade dress, trademarks, artwork and associated imagery are trademarks and/or copyright material of their respective owners. All rights reserved. [more info]
