Opened 9 years ago

Closed 8 years ago

#802 closed enhancement (complete)

Server-side code on boss to handle requests for new sockets

Reported by: stephen Owned by: vorner
Priority: medium Milestone: Sprint-20111220
Component: ~Boss of BIND (obsolete) Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DNS Feature Depending on Ticket: Socket creator
Estimated Difficulty: 6 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description (last modified by stephen)

Note that two components may request the same socket. This will cause unexpected behavior, so we should prevent that at some point.

We should issue a warning from attempts to use a wildcard binding, until we come up with a solution for insuring we send UDP answers on the same interface in IPv4.

This process may or may not be blocking.

Note: We now require boss to run processes that need sockets.


Change History (11)

comment:1 Changed 9 years ago by stephen

  • Description modified (diff)

comment:2 Changed 9 years ago by vorner

Just one note, the vorner-sockcreator branch has tests for this in its last two or three commits, they might be useful. The tests will not be merged with #366 (because it fails, the functionality is not yet implemented).

comment:3 Changed 9 years ago by vorner

Ups, sorry, wrong ticket. The last comment should belong to ticket #800.

comment:4 Changed 8 years ago by jelte

  • Defect Severity set to N/A
  • Estimated Difficulty changed from 0.0 to 6
  • Sub-Project set to DNS

comment:5 Changed 8 years ago by jelte

  • Milestone changed from Year 3 Task Backlog to Sprint-20111206

comment:6 Changed 8 years ago by vorner

  • Owner set to vorner
  • Status changed from new to accepted

I might split some tickets off this, once I have a look into what is needed. But some experiments first, anyway.

comment:7 Changed 8 years ago by vorner

  • Owner changed from vorner to UnAssigned
  • Status changed from accepted to reviewing


So, I'd like to split the ticket to three parts:

  • A ticket to create a unix domain listening socket and provide a function handling when new data arrive on whatever socket that connects there. The handling function should be empty in this socket, just making sure the boss can handle multiple sockets and the data are read.
  • A ticket to implement the caching of sockets.
  • A ticket to connect these two together and add the commands on message queue to create the sockets.

It is related to the creatorapi.txt design in bin/bind10.

The overall architecture/codeflow would be like this:

  • A request with bunch of details about address, etc, is received over msgq.
  • A token representing the socket is obtained from the cache and sent back over msgq. If there's a failure, the failure is sent over the msgq back and we stop here.
  • The application connects to the unix domain socket and sends the token there. It keeps the connection open forever (actually, if it already has one opened, it can reuse that one).
  • The read data from unix domain is triggered.
  • The token is passed back to the cache, the socket gets out and is sent over the unix domain socket.
  • If application stops using a socket, it says so over the msgq with the corresponding token and the cache is informed about it.
  • If application dies, the unix domain socket is closed automatically. Boss informs the cache and all sockets sent over the given unix domain sockets are considered unused any more.

I propose the new-data function in boss would be:

def socket_request_handler(self, token, unix_socket)

I also pushed a proposed interface for the cache to this branch. The interface over the msgq is up to the third subtask. I propose the token be sent over the unix domain socket as a single line, so we can easily separate multiple tokens there.

After this is reviewed and ACKed, I'd like to create the three tickets, which can be then done in parallel. I'd like to keep this task open then as a meta-ticket and close it after all three are done and we check that it fits together well.

Thank you

comment:8 Changed 8 years ago by jelte

  • Owner changed from UnAssigned to vorner

Not sure I entirely agree with the naming here (is it really a cache? and the name of get_token() doesn't really suggest it creates the socket :p) but at this point I have no better suggestions.

A couple of suggested comment fixes;

in class SocketError?: unsufficient->insufficient
in class ShareError?: Such->The requested, doesn't->do not
in get_token: SockeError?->SocketError?

Since I have no better ideas for the naming, please go ahead and create the sub-tickets, and we'll consider this the meta-ticket from now on.

comment:9 Changed 8 years ago by vorner

OK, tickets created as #1427, #1428 and #1429.

comment:10 Changed 8 years ago by shane

  • Feature Depending on Ticket set to Socket creator

comment:11 Changed 8 years ago by vorner

  • Resolution set to complete
  • Status changed from reviewing to closed

Everything merged together and to master. Closing.

Note: See TracTickets for help on using tickets.