Some thoughts about sockets

I’m deciding, what is more important: syntax compatibility with usual sockets implementation (mimic function declarations and function appearing in user code order as much as possible ) or basic compatiblility (module behaviour is similar, but some functions named differently and function sequences to establish connection may be another) is more than enough. May be it’s one task, but views from two sides. This day I’m thinking first variant is more appropriate, but it limits some project functionality available with current understanding of pxe_filter.
All incoming packets flows from hidden (may be not hidden, anyway userbased networking needs receive cycle) from user pxe_core_recv_packets() function to registered by IP based protocol callback function (e.g. for UDP – pxe_udp_callback(), installed by pxe_udp_init() call at pxe_core startup). Callback function must dispatch packet data to one of sockets, if any inited.

For that purpose Ive create module, named pxe_filter. Every socket at eatablishing connection time (or at time of equivalent of listen() call, or just at socket creating time) installs filter to filter table. Filter conatains destination/source ip/port with masks for every parameter and reference to socket, for which installed filter. So, protocol handler function starts pxe_filter_check() with extracted from packet values of ports, ips and protocol type. Filter check function sequentialy checks filter entries from start to end entry, and returns when (if) first satisfactory entry found (well, similar to firewall rules). If filter entry found, socket is extracted from pxe_filter_entry structure and socket member of structure is valid – data dispatched to the socket buffer, if there is free space in it.

What benefits it gives:

  • it’s simple. And it adds some functionality of primitive firewall (which may be not interesting in this project).
  • not connection oriented code may listen only that ip in whcih it interested. Usually check from which ip datagram received is performed after recvfrom () or recvmsg() by one of returned values. But in case of filters – there would no necessity in this. Filter may limit from which ip to get packets. I think, it’s useful, e.g. for DNS resolver or any other non broadcast UDP packets transmiting, when it’s known from which ip data expected. If mimic absolutely sockets function syntax, this functionality may be lost.
  • listen() call may use filter to “fork” sockets, creating socket with more strict filter higher (earlier in checking order) in filter table. So all accepted connections may be assumed as child to base socket. And it’ll help to check if there are more connections to accept and after closing of base socket – which connections also to kill, if needed. Well, my project is more client oriented, than server, but anyway good opportunity.

For me, it seems not bad idea at all, so I’ve started doing it in this way.

PS:

can someone say how to fix SpamKarma 2, which is installed incorrectly? all links from manage page links to freebsdish.org/wp-admin/… but not to freebsdish.org/taleks/wp-admin/… it’s a little bit annoying to enter manually

…/taleks/wp-admin/options-general.php?page=spamkarma2&

sk2_section=spam&sql_rows_per_page=20&

sql_skip_rows=0&sql_score_threshold=-100 to check if some comment is mistaken with cialis ads.

Leave a Reply