[zeromq-dev] Problem: ipc:// does not work on Windows

Doron Somech somdoron at gmail.com
Fri Oct 3 12:30:54 CEST 2014


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 <ph at imatix.com> 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 <somdoron at gmail.com> 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 <ph at imatix.com> 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
> >> zeromq-dev at lists.zeromq.org
> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >
> >
> >
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20141003/236c5bf1/attachment.htm>


More information about the zeromq-dev mailing list