I think both connect and bind have to check the file. It doesn't need cleaning up IMO: as long as the IPC endpoints aren't duplicated. It becomes a persistent map from endpoint to socket. Indeed, either connect or bind can create a new entry (same algorithm: lock file, look for entry, create one if it's missing).
Come to think of it we don't need the hashing, if we use a locked file. Random port or sequential port, it'll all work. We should probably use a range outside (below) the normal ephemeral range (49152 to 65535) to avoid conflicts with normal use. I'd suggest a block before 49152. On Fri, Oct 3, 2014 at 12:30 PM, Doron Somech <[email protected]> wrote: > Ok, and the client should always check the file anyway? > > So I think we can get rid of the cleanup, but the file can be big if it > append only. > > I suggest we allocate fix size for each entry in the file, the first entry > in the file will be the first port in the ephemeral port range, we actually > don't need to write the port, only the address because the port is indexed. > > The binding socket enter the mutex and try to bind according to the hashed > port and increase on failure, when succeeding the server write the address > to the correct location at the file terminated by '\0' and exit the mutex. > > The connecting socket enter the mutex and search for the address, starting > at the hashed location, then exit the mutex. > > The last question is do we want to hash or just use ephemeral port, the > advantage of hashing is quicker search for the connecting socket but slower > binding for the server. Using ephemeral port will be a little easier to > implement and quicker for the binding socket, however the connecting socket > will have to search the entire file. > > On Thu, Oct 2, 2014 at 11:27 PM, Pieter Hintjens <[email protected]> wrote: >> >> How about a mix of hashing and text file? That means a given endpoint >> will always use the same port by default, and then we can increment to >> find a free port. This removes most/all the problems of cleaning up, I >> think. >> >> On Thu, Oct 2, 2014 at 5:32 PM, Doron Somech <[email protected]> wrote: >> > I would go with mutex and shared file, but I think it is complicated to >> > implement, because every time socket connects it has to check the file >> > and >> > cannot actually use hashing. The problems with hashing: >> > >> > * Try to bind and port is taken ? >> > * Try to connect but the peer is not zeromq >> > * Try to connect and the peer is zeromq but not the one I actually want. >> > >> > Because of the third problem we will have to check the file on every >> > connect >> > which mean we don't need the hashing, just the file. >> > >> > So we have a file, every time we bind we bind to ephemeral port and >> > write a >> > row to the file with the port and the name and every time we connect we >> > check the file, but the remain case is when do we clear the file? >> > >> > >> > >> > >> > >> > On Thu, Oct 2, 2014 at 3:12 PM, Pieter Hintjens <[email protected]> wrote: >> >> >> >> This is annoying mainly because it hurts code portability and also >> >> because ipc:// (especially with abstract endpoints) is a nicer >> >> semantic for local services than TCP ports. e.g. I've a protocol >> >> called zccp and the default location for a zccp broker is >> >> ipc://@/zccp. >> >> >> >> Solution: cheat, on Windows >> >> >> >> Real solution: accept "ipc://" endpoints and hash them to a socket >> >> number in the ephemeral range, then bind/connect on 127.0.0.1 with >> >> that port number. >> >> >> >> Difficulty: hash conflicts. :-) >> >> >> >> If anyone has a plausible solution to hash conflicts (registry?) then >> >> this should be quite simple to make. >> >> >> >> -Pieter >> >> _______________________________________________ >> >> zeromq-dev mailing list >> >> [email protected] >> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > >> > >> > >> > _______________________________________________ >> > zeromq-dev mailing list >> > [email protected] >> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
