[zeromq-dev] Requesting suggestions for getsockopt() in Java
gdiethelm at dcv.cl
Wed Aug 11 16:06:24 CEST 2010
> I took that to mean they have those two low-level native methods
> (probably declared as protected or private), and implement all the
> high-level methods (such as the ones I listed for 0MQ) by calling
> two. This would make sense to me (#1).
> It also makes sense (in an OO world) to NOT use the "Socket" word;
> are socket objects anyway, so we should have setHWM() and getRate()
> Finally, if we go this way I would like to deprecate (or simply
> eliminate) the two setsockopt() methods and all the socket option
> constants that are declared in ZMQ.java (#3).
I have just committed a change that eliminates the two setsockopt()
methods in the Socket class and adds the following methods:
void setHWM(long hwm);
void setSwap(long swap);
void setAffinity(long affinity);
void setIdentity(String identity);
void setSubscribe(String subscribe);
void setUnsubscribe(String unsubscribe);
void setRate(long rate);
void setRecoveryInterval(long recovery_ivl);
void setMulticastLoop(boolean mcast_loop);
void setSendBufferSize(long sndbuf);
void setReceiveBufferSize(long rcvbuf);
There are three methods "missing" because they don't really make sense:
void setReceiveMore(boolean rcvmore);
I went the easy road and simply added four native methods to implement
all the previous ones; a further refinement might be to coalesce these
four into two methods using Object (I have no definite plans to do
protected native long getLongSockopt (int option);
protected native String getStringSockopt (int option);
protected native void setLongSockopt (int option,
protected native void setStringSockopt (int option,
Now, some comments.
1. I have doubts regarding the use of String vs. byte for things like
setIdentity() and getIdentity(); I am not sure how those methods will
behave in the presence of strings with '\0' embedded in them.
2. I also have doubts regarding the use of long vs. int in all these
methods. Does it make any difference?
3. Finally, the 0MQ documentation sometimes uses int64_t and sometimes
uint64_t for several of the socket options, even mixing the two types
for a given option when setting or getting it. Is this on purpose?
More information about the zeromq-dev