Re: [U2] Socket universe vs d3
Tony Gravagno wrote: This is one of the unfortunate issues of using sockets from MV. Part of the problem is that the MV DBMS is an application over the OS, and the handle to the socket is only released if the MV monitor explicitly releases it. If you whack an MV process without allowing it to go through a proper wrapup, then the host OS doesn't know that the socket should be available, so SO$REUSEADDR is useless anyway. In the case of D3, the only way to release a socket that's been whacked like this is to reboot D3 itself - a major pain to get all users off the system to release a single socket - and for this reason I discourage use of D3 as a socket server. I'd be interested to know if U2 is any more adept at handling this scenario. I guess it comes down to the definition of the word whacked and how well U2 handles such conditions. Well on D3 Unix/Linux no need to reboot D3 to release sockets, only on d3 windows, I think. I'm currently porting jd3 from d3 to universe in fact. Socket are okay for us with a program like jd3 Cedric --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Socket universe vs d3
Craig Bennett wrote: Hi Cedric, I think the UniVerse equivalent would be: err = initServerSocket(, ser.port, backlog, sock) err = acceptConnection(sock, timeout, client.addr, client.name, client.sock) loop while 1 do send/revceive using client.sock repeat Thanks, it seems good now... In fact, I'm trying to move jd3 (java-d3, see http://www.djpatterson.com/jd3php.html) from Pick D3 to Universe. It's a way to communicate from apache/php to a multivalued DB. If some people are interested here, universe_jd3 will be GPL and I think we may release an alpha version by september. Cedric --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Socket universe vs d3
Processes operating as socket servers can only serve one process at a time, regardless of which OS or DBMS platform creates the socket. SO$REUSEADDR is intended to eliminate the TIME_WAIT state if the process running the listener happens to die. If there is no step in U2 between init and accept then if the process dies you'll just have to accept the fact that you can't use the socket until the handle is released. This is one of the unfortunate issues of using sockets from MV. Part of the problem is that the MV DBMS is an application over the OS, and the handle to the socket is only released if the MV monitor explicitly releases it. If you whack an MV process without allowing it to go through a proper wrapup, then the host OS doesn't know that the socket should be available, so SO$REUSEADDR is useless anyway. In the case of D3, the only way to release a socket that's been whacked like this is to reboot D3 itself - a major pain to get all users off the system to release a single socket - and for this reason I discourage use of D3 as a socket server. I'd be interested to know if U2 is any more adept at handling this scenario. I guess it comes down to the definition of the word whacked and how well U2 handles such conditions. I don't do U2 sockets but I'm guessing Craig's code is missing something. In socket comms, you wait on the listen, accept a connection, do whatever you need, then go back to listen. Looping on accept is OK but after the repeat you have to go back to listening, and that shouldn't mean going back to the initServerSocket unless an existing socket goes immediately to listen. Tony TG@ removethisNebula-RnD .com Craig Bennett wrote: It looks to me like you are using SO$REUSEADDR to allow multiple processes to share the same address/port. As far as I am aware this will not work under U2 because the setSocketOptions can only be called after initServerSocket which includes the bind and listen operations (I recall this from a post be Ken Wallis a few years back, so I could be wrong or U2 could have changed). Because of this, in U2 I think you would: loop err = accepConnection(sock, timeout, client.addr, client.name, client.sock) while 1 do repeat since one process must server all your socket requests one by one. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Socket universe vs d3
Tony, I don't do U2 sockets but I'm guessing Craig's code is missing something. In socket comms, you wait on the listen, accept a connection, do whatever you need, then go back to listen. Looping on accept is OK but after the repeat you have to go back to listening, and that shouldn't mean going back to the initServerSocket unless an existing socket goes immediately to listen. once you initServerSocket in UV, any other process trying to initServerSocket on the same ip/port combination fails. It looked to me like Cedric was using SOREUSEADDR to allow multiple D3 processes to handle incoming connections (using SOREUSEADDR so that mutiple processes could listen in turn for incoming connections ... maybe D3 doesn't work like this and I misunderstood his code?). Such a design won't work under UV as you have no way to apply the SOREUSEADDR option to the listener. So you need to loop on acceptconnection and then loop on read/write operations until you are done with a client connection and then accept the next connection (or accept multiple connections into the one process and have your program service each one in a loop). I will admit that I haven't bothered with UV socket servers since 9.6 because of these limitations. Craig --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Socket universe vs d3
D3 works just like UV in this regard, only one process can listen on a socket port at any given time, processes can't be forked or otherwise handed off, etc. As I said though, after the code has exhausted all of your inbound connections via Accept, it needs to go back to a Listen which, depending on flags, may or may not wait for new inbound connections. I'm sure the answer to this is in the docs. The best ways (IMO) to implement sockets with MV platforms are (1) as a client-only, connecting to a middle-tier that actually does proper server processing, (2) to pass all comms functions to a middle tier and then call into MV apps to process requests, or (3) to implement a custom socket library via DBMS-specific C interfaces or monitor rebuilding. Option 3 is highly discouraged. How to do option 2 has been discussed here many times. Option 1 is complex but arguably worth the effort. HTH someone. T Craig Bennett wrote: once you initServerSocket in UV, any other process trying to initServerSocket on the same ip/port combination fails. It looked to me like Cedric was using SOREUSEADDR to allow multiple D3 processes to handle incoming connections (using SOREUSEADDR so that mutiple processes could listen in turn for incoming connections ... maybe D3 doesn't work like this and I misunderstood his code?). Such a design won't work under UV as you have no way to apply the SOREUSEADDR option to the listener. So you need to loop on acceptconnection and then loop on read/write operations until you are done with a client connection and then accept the next connection (or accept multiple connections into the one process and have your program service each one in a loop). I will admit that I haven't bothered with UV socket servers since 9.6 because of these limitations. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] Socket universe vs d3
Hello, I'm trying to port a program using socket from D3 to Universe and syntaxes seems to be slightly different... This program is a server, so it listens on a port and wait for incoming connection. In an easy way, here how it works on d3 sock = %socket(AF$INET, SOCK$STREAM, 0) err = %setsockopt(sock, SOL$SOCKET, SO$REUSEADDR, one, 1) err = %bind(sock, AF$INET, INADDR$ANY, ser.port) %listen(sock, 3) loop while 1 do send/receive operations repeat While I'm able to do main operation, I can't find a commande like listen on u2 socket implementation. How could I wait for connection on the listening port ? Thanks Cedric Fontaine --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Socket universe vs d3
Hi Cedric, sock = %socket(AF$INET, SOCK$STREAM, 0) err = %setsockopt(sock, SOL$SOCKET, SO$REUSEADDR, one, 1) err = %bind(sock, AF$INET, INADDR$ANY, ser.port) %listen(sock, 3) loop while 1 do send/receive operations repeat I think the UniVerse equivalent would be: err = initServerSocket(, ser.port, backlog, sock) err = acceptConnection(sock, timeout, client.addr, client.name, client.sock) loop while 1 do send/revceive using client.sock repeat -- It looks to me like you are using SO$REUSEADDR to allow multiple processes to share the same address/port. As far as I am aware this will not work under U2 because the setSocketOptions can only be called after initServerSocket which includes the bind and listen operations (I recall this from a post be Ken Wallis a few years back, so I could be wrong or U2 could have changed). Because of this, in U2 I think you would: loop err = accepConnection(sock, timeout, client.addr, client.name, client.sock) while 1 do repeat since one process must server all your socket requests one by one. HTH, Craig --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
