Hi Albert,

Here's an outline of the proposed book - what do you think? Any chapters
really take your fancy?

Gerard

-----Original Message-----
From: Albert Castillo [mailto:albert.castillo@s...]
Sent: 15 December 2002 22:38
To: Pro Linux Programming
Subject: [pro_linux_programming] RE: RAW sockets multithreaded server.
Ple ase help!


Gerard,

Hello. My name is Albert Castillo. I read your post to the Professional 
Linux Programming forum asking for help on creating a spec for a Linux 
Networking book. I have some good experieince with Linux network 
programming and may be able to help you out. I have my own consulting 
company (SFM) and do a lot of Linux networking stuff.

Do you still need help with the spec? Can you give me your email address 
so I can email you direct?

I would also be very interested in authoring and/or co-authoring the book 
for you! Do you have an author yet?

Albert :)

> Hi Guys,

> I'm working on a specification for a Linux Networking book at the 
moment, 
a> nd this thread caught my eye..

> Would any of you guys like to participate in the spec creation process?

> Drop me an e-mail if you think it sounds interesting, but move quickly 
p> lease - we don't have much time!!

> Thanks,

> Gerard Maguire
C> ommissioning Editor
W> rox Press

> 
>>  Hello,

> I'm working right now on DIPC networking in Linux.
I>  would suggest to use UDP/IP communications instead of RAW sockets.
I> t is faster than TCP and more reliable than RAW packets.
N> ow you can have multicast addresses assigned to some of your client(s)
a> nd send packet only to those clients on the same multicast address or 
y> ou can assign a unique port addresses between clients. Port number 
d> atabase
y> ou can keep on your server.
U> DP gives you some advantages over RAW sockets and speed is pretty close 
to
R> AW sockets.
T> he problem with RAW and UDP sockets that if you have multi-packet
t> ransmition, you need to 
t> ake care of missing and corrupted packet because of the nature of those
t> ypes of communications. A packet
c> an be dropped or corrupted and it is up to programmer to create logic to
c> heck consistency of a transmition.

> I'll be glad to answer any specific questions.

> Regards,
K> onstantyn.

> PS: Greetings from USA :)

> 
-> ----Original Message-----
F> rom: kreez [mailto:insperactive@m...]
S> ent: Friday, November 15, 2002 8:10 PM
T> o: Pro Linux Programming
S> ubject: [pro_linux_programming] RAW sockets multithreaded server.
P> lease help!

> 
H> i! Greetings from Russia!
T> here are no expert or skilled linux programmers in Russia, so nobody 
c> ould help me to cope
w> ith 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 
t> ime strategy game 
(> server under Linux and client for Windows). I chose RAW sockets for net 
t> raffic economy.
S> o, there's the situation:
 > The server consists of the parent thread (including the socket itself) 
a> nd the child threads
w> hich are responsible for intercommunication with the gamers (clients). 
O> nce the gamer is registered
o> n the server the child thread is created and "constantly linked" with 
the 
c> lient. There are about 1000 threads (gamers)
c> onstantly running and performing their job. Threads but not processes 
are 
c> hosen because they easily share common
d> ata (dynamic memory) by default (for example, in-game maps, statistics, 
e> tc.). In fact the gamer's "kingdom" is
r> eigned and ruled by the AI and the user just takes control on whatever 
p> art of his kingdom or a unit he needs to 
(> that allows the "kingdom" to exist even when the gamer himself is 
o> ffline). The socket is shared between the child threads
(> one per all). When a user (user "A" for instance) performs some action 
in 
t> he client window the client program sends a 
R> AW IP packet to the server. Next the server child thread which is 
r> esponsible for user "A" should receive the packet
a> nd change the game situation... But the RAW IP packets are passed to 
the 
r> andom thread (or all threads) by the Linux kernel!
H> ow can I make the packet to reach only one concrete thread? I mean how 
to 
m> ake the thread "A" receive only user "A" packets,
a> nd thread "B" - only packet from the user "B"? By default the Linux 
k> ernel redirects RAW IP packets to the socket
w> ith the same protocol number. But the protocol is the same for all 
t> hreads - RAW IP protocol number 255. And the socket is
t> he same. It is created and initialized in the parent thread once the 
s> erver is started. The scheme should be like
t> his: The server holds a simple database of the user IDs and IPs. The 
IDs 
a> re unique for each user and they are constant
w> hile IPs can change. When the client sends a packet the server stores 
the 
s> ource IP and checks the data included in the 
p> acket (ID). Then it sets a "logical link" between the ID and the IP and 
p> asses the structure containing ID and IP to the
c> oncrete child thread which is to communicate with that ID. The child 
t> hread is started when the user is registered 
(> the first time and then the user can "disconnect - exit the server" 
a> nd "connect - join the game again" while the 
c> hild thread will still run on) and the thread runs driven by the AI 
until 
t> he user is "virtually dead". 
C> an you help me on how to perform it? 
O> r maybe you can give me and advice on the other method of creating such 
a 
f> ramework?
T> hanks a lot. Sorry for my English. 
-> --
C> hange your mail options at 
t> o unsubscribe send a blank email to
%> %email.unsub%%.