Hello,

I'm working right now on DIPC networking in Linux.
I would suggest to use UDP/IP communications instead of RAW sockets.
It is faster than TCP and more reliable than RAW packets.
Now you can have multicast addresses assigned to some of your client(s)
and send packet only to those clients on the same multicast address or 
you can assign a unique port addresses between clients. Port number database
you can keep on your server.
UDP gives you some advantages over RAW sockets and speed is pretty close to
RAW sockets.
The problem with RAW and UDP sockets that if you have multi-packet
transmition, you need to 
take care of missing and corrupted packet because of the nature of those
types of communications. A packet
can be dropped or corrupted and it is up to programmer to create logic to
check consistency of a transmition.

I'll be glad to answer any specific questions.

Regards,
Konstantyn.

PS: Greetings from USA :)


-----Original Message-----
From: kreez [mailto:insperactive@m...]
Sent: Friday, November 15, 2002 8:10 PM
To: Pro Linux Programming
Subject: [pro_linux_programming] RAW sockets multithreaded server.
Please help!


Hi! Greetings from Russia!
There are no expert or skilled linux programmers in Russia, so nobody 
could help me to cope
with my problem. There's a kind of information and knowledge deficit... :(.
I am trying to develop a multithreaded C++ socket framework for a net real 
time strategy game 
(server under Linux and client for Windows). I chose RAW sockets for net 
traffic economy.
So, there's the situation:
 The server consists of the parent thread (including the socket itself) 
and the child threads
which are responsible for intercommunication with the gamers (clients). 
Once the gamer is registered
on the server the child thread is created and "constantly linked" with the 
client. There are about 1000 threads (gamers)
constantly running and performing their job. Threads but not processes are 
chosen because they easily share common
data (dynamic memory) by default (for example, in-game maps, statistics, 
etc.). In fact the gamer's "kingdom" is
reigned and ruled by the AI and the user just takes control on whatever 
part of his kingdom or a unit he needs to 
(that allows the "kingdom" to exist even when the gamer himself is 
offline). The socket is shared between the child threads
(one per all). When a user (user "A" for instance) performs some action in 
the client window the client program sends a 
RAW IP packet to the server. Next the server child thread which is 
responsible for user "A" should receive the packet
and change the game situation... But the RAW IP packets are passed to the 
random thread (or all threads) by the Linux kernel!
How can I make the packet to reach only one concrete thread? I mean how to 
make the thread "A" receive only user "A" packets,
and thread "B" - only packet from the user "B"? By default the Linux 
kernel redirects RAW IP packets to the socket
with the same protocol number. But the protocol is the same for all 
threads - RAW IP protocol number 255. And the socket is
the same. It is created and initialized in the parent thread once the 
server is started. The scheme should be like
this: The server holds a simple database of the user IDs and IPs. The IDs 
are unique for each user and they are constant
while IPs can change. When the client sends a packet the server stores the 
source IP and checks the data included in the 
packet (ID). Then it sets a "logical link" between the ID and the IP and 
passes the structure containing ID and IP to the
concrete child thread which is to communicate with that ID. The child 
thread is started when the user is registered 
(the first time and then the user can "disconnect - exit the server" 
and "connect - join the game again" while the 
child thread will still run on) and the thread runs driven by the AI until 
the user is "virtually dead". 
Can you help me on how to perform it? 
Or maybe you can give me and advice on the other method of creating such a 
framework?
Thanks a lot. Sorry for my English.