Re: basic and complite implementation of socket

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 19:08 Sat 15 Nov     , siddharam suresh wrote:
> Hi sir
> i got the source code of the bind,connect,socket system calls the definition
> of these system calls is available in file called as "/net/socket.c" to
> browse this code i am using ctags
> i want to know about the how this sys_socket,sys_connect,sys_bind  are
> implemented

sys_socket looks for a registered protocol which matches the proto id you
specified when calling socket(). For ipv4, the registration takes place in
net/ipv4/af_inet.c (function inet_init)

When creating the socket, the socket operations are assigned (e.g. to
inet_stream_ops). These operation define the behaviour of connect, bind, ...

> Is there any possibility to access the incoming data (that is data from
> socket buffer/or ether net buffer ) by multiple process (these mustiple
> server process on same machine but client is on different machine server and
> client are connected the TCP connection)

Yes, there is.

You can create the processes not by calling fork(), but by clone and specify
CLONE_FILES. If this cannot be done, you can try to send the socket through
a unix domain socket. This is described in "man cmsg", but I have never seen
anybody doing this.

> for example the  client sends 1,2,3,4,5,6 as the data
> there must be two process they must read these data like
> process 1: 1,2,3
> process 2: 4,5,6

It is not that easy. The 2 processes may *not* call recv or send at the
same time. If they do, the behaviour is undefined. This means e.g. that the
data might be interleaved. Even if it is not, this behaviour may change in
future kernel versions without any notice. You *have* to do the locking
yourself. At least in order to make sure that you can read/send as much as you
want without any other process taking away your data or sending something in
between. Remember recv/send does *can* return with less than the specified
buffer space received/written.
	-Michi
-- 
programing a layer 3+4 network protocol for mesh networks
see http://michaelblizek.twilightparadox.com


--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux