hiho@ll

what i want to do:
i want write some functions which are able to create a socket descriptor for me which i can use with standard read(); and write(); functions and every socket function which is available in the socket api BUT i don't want that the socket gets opened by the three way handshake

explanation:
read this scenario (it's just an example and has nothing to do with final sense of my question, it only describes what i want to do):
1. HOST A (192.168.0.1) connects to HOST B (192.168.0.2) on port 0xcafe
2. HOST C (192.168.0.3) connects to HOST B
3. HOST B sends every information which is needed by HOST C (i don't know which information is needed, this is another part of my topic here) to USE the already opened connection between HOST A and HOST B.
4. HOST C sends a packet to HOST A through a socket descriptor for which NO three way handshake has been done, because:
HOST A thinks it gets the packet from HOST B

to help you understand this i would also explain it this way:
i want to do something like "connection sharing"
i know there are some attacks which fake the sender ip address of the packet so they can do a DoS attack or such stuff
i don't want it that way! i want that the connection, which has been opened by HOST B, can be used by HOST C without using HOST B as a gateway! i want that HOST A and HOST C can communicate directly

another way of explanation:
if you look at HOST A only ONE connection has been opened, but 2 HOSTS (HOST B and HOST C) are able to communicate independent of each other
i know if this works i have many synchronization problems, but for now i only want to know
if this works?
how does this work?
will it be a kernel hack? or can i use socket api functions? (maybe raw sockets (never used it) or such stuff)
any resources on this topic would be great?
a source code example would be perfect but i want to do it by myself, for learning purpose ...

the second step would be that HOST B can close his socket without affecting the connection of HOST C
the third step would be to synchronize the whole stuff
but that's not my main problem now ;-)

thx@ll

I don't think it is possible to do what you want. At least not as I understood it!

You can use UDP datagrams to have a stateless connection but they will still be reliant on the IP address & ultimately the MAC address of the network interface. So you could send data from B and C to A without a 'connection' you could even get C to change the IP address so that A thinks it comes from B but when A replies it will send the modified packet from C back to B, because that is where it though it came from. B could then be programmed to forward it on but this would fail as soon as B drops out of the loop.

Having said that you may want to look further into UDP datagrams in that they may provide enough of what you wanted to get going. They don't have the three way handshake but they do generate their own connection information on the transport layer stack. This allows for a reply to the machine with a simple write, but the machine's IP details are known.

graeme.

hmm
yes UDP would be a possibility in a different way

but that's not the challenge i want to try ;-)
maybe later

to make it clear so i understand
the problem is that the kernel associates a socket with a destination mac address and destination ip/port?
correct?
so the kernel would simply discard my packet from HOST C because the source address of the packet is not the same as from HOST B who created the connection
OR
the kernel would simply send the response to HOST B and only ignores that the source of the request came from HOST C

is that the main problem?

if yes it seems there is a need for a new api supported by the kernel --> it's a kernel hack *damn*

right?

What you need is multicast. The thing is that you'd need to do it in a real multicast, not something emulated over unicast IP. That may be a problem because of the addressing etc. If you're doing a thing that's not very complicated, it seems easier to do it all using standard sockets connecting two hosts each.

hmm
i read a bit about raw sockets and multicast

as i understood multicast is just sending messages to more than one host and less than all hosts (broadcast)
and this seems to be done through udp
or some other multicast protocols which are available

so it seems that i want to make a tcp multicast
and i think it should be possible

just using raw sockets (neither the server nor the client can use the simple socket api, they have to use raw sockets, i think)
so i could use a subnet mask and do a logical & with the IP address received so i know WHO wants to talk and who is allowed to talk to the multicast server
and every host (server or client) has to set the network interface in promiscuous mode so it can read every packet which is received

using this scenario (and make it a bit better, but its an approach) it should be possible to do multicasts using tcp
i think i could use libnet library

if this works i have a good "one to many" or "many to many" tcp inter process communication technique which would work locally or over the network
the problem is that only root can use it because of raw sockets

TCP and multicast are mutually exclusive. It is not the Linux kernel that prevent you to do that, but the TCP/IP standard.

TCP is maintaining data offset to make sure the flow of bytes travelling between two hosts are orderly sent to the upper layer application. Having more than two actors in the party breaks that.
As others already wrote, you'd better either go the UDP/multicast way, or have separated TCP connections handling.

ok
seems i misunderstood something

so i have to use a multicast protocol instead of tcp
such as SCTP, SRM, MFTP or something

thx@ll

One way is indeed to use IP multicasting, and on top of that, one existing protocol that is compatible with multicast (UDP being the best candidate), and on top of UDP, either use another existing protocol if one fit your needs or just build your own ...
You can also go a more experimental way and try IP alternatives: SCTP, reliable multicast an the likes.