geom_gate userland utility improvements
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

ggated.c 27 KiB

14 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
Reimplement ggatec/ggated applications. Change communication protocol to be much more resistant on network problems and to allow for much better performance. Better performance is achieved by creating two connections between ggatec and ggated one for sending the data and one for receiving it. Every connection is handled by separeted thread, so there is no more synchronous data flow (send and wait for response), now one threads sends all requests and another receives the data. Use two threads in ggatec(8): - sendtd, which takes I/O requests from the kernel and sends them to the ggated daemon on the other end; - recvtd, which waits for ggated responses and forwards them to the kernel. Use three threads in ggated(8): - recvtd, which waits for I/O requests and puts them onto incoming queue; - disktd, which takes requests from the incoming queue, does disk operations and puts finished requests onto outgoing queue; - sendtd, which takes finished requests from the outgoing queue and sends responses back to ggatec. Because there were major changes in communication protocol, there is no backward compatibility, from now on, both client and server has to run on 5.x or 6.x (or at least ggated should be from the same FreeBSD version on which ggatec is running). For Gbit networks some buffers need to be increased. I use those settings: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 and I use '-S 4194304 -R 4194304' options for both, ggatec and ggated. Approved by: re (scottl)
19 years ago
12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697989910010110210310410510610710810911011111211311411511611711811912012112212312412512612712812913013113213313413513613713813914014114214314414514614714814915015115215315415515615715815916016116216316416516616716816917017117217317417517617717817918018118218318418518618718818919019119219319419519619719819920020120220320420520620720820921021121221321421521621721821922022122222322422522622722822923023123223323423523623723823924024124224324424524624724824925025125225325425525625725825926026126226326426526626726826927027127227327427527627727827928028128228328428528628728828929029129229329429529629729829930030130230330430530630730830931031131231331431531631731831932032132232332432532632732832933033133233333433533633733833934034134234334434534634734834935035135235335435535635735835936036136236336436536636736836937037137237337437537637737837938038138238338438538638738838939039139239339439539639739839940040140240340440540640740840941041141241341441541641741841942042142242342442542642742842943043143243343443543643743843944044144244344444544644744844945045145245345445545645745845946046146246346446546646746846947047147247347447547647747847948048148248348448548648748848949049149249349449549649749849950050150250350450550650750850951051151251351451551651751851952052152252352452552652752852953053153253353453553653753853954054154254354454554654754854955055155255355455555655755855956056156256356456556656756856957057157257357457557657757857958058158258358458558658758858959059159259359459559659759859960060160260360460560660760860961061161261361461561661761861962062162262362462562662762862963063163263363463563663763863964064164264364464564664764864965065165265365465565665765865966066166266366466566666766866967067167267367467567667767867968068168268368468568668768868969069169269369469569669769869970070170270370470570670770870971071171271371471571671771871972072172272372472572672772872973073173273373473573673773873974074174274374474574674774874975075175275375475575675775875976076176276376476576676776876977077177277377477577677777877978078178278378478578678778878979079179279379479579679779879980080180280380480580680780880981081181281381481581681781881982082182282382482582682782882983083183283383483583683783883984084184284384484584684784884985085185285385485585685785885986086186286386486586686786886987087187287387487587687787887988088188288388488588688788888989089189289389489589689789889990090190290390490590690790890991091191291391491591691791891992092192292392492592692792892993093193293393493593693793893994094194294394494594694794894995095195295395495595695795895996096196296396496596696796896997097197297397497597697797897998098198298398498598698798898999099199299399499599699799899910001001100210031004100510061007100810091010101110121013101410151016101710181019102010211022102310241025102610271028102910301031103210331034103510361037103810391040104110421043104410451046104710481049105010511052105310541055105610571058105910601061106210631064106510661067106810691070107110721073107410751076107710781079108010811082108310841085108610871088108910901091109210931094109510961097109810991100110111021103110411051106110711081109111011111112111311141115111611171118111911201121112211231124112511261127112811291130113111321133
  1. /*-
  2. * SPDX-License-Identifier: BSD-2-Clause-FreeBSD
  3. *
  4. * Copyright (c) 2004 Pawel Jakub Dawidek <pjd@FreeBSD.org>
  5. * All rights reserved.
  6. *
  7. * Redistribution and use in source and binary forms, with or without
  8. * modification, are permitted provided that the following conditions
  9. * are met:
  10. * 1. Redistributions of source code must retain the above copyright
  11. * notice, this list of conditions and the following disclaimer.
  12. * 2. Redistributions in binary form must reproduce the above copyright
  13. * notice, this list of conditions and the following disclaimer in the
  14. * documentation and/or other materials provided with the distribution.
  15. *
  16. * THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``AS IS'' AND
  17. * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  18. * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  19. * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE
  20. * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
  21. * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
  22. * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  23. * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
  24. * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
  25. * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  26. * SUCH DAMAGE.
  27. *
  28. * $FreeBSD$
  29. */
  30. #include <sys/param.h>
  31. #include <sys/bio.h>
  32. #include <sys/disk.h>
  33. #include <sys/endian.h>
  34. #include <sys/ioctl.h>
  35. #include <sys/queue.h>
  36. #include <sys/socket.h>
  37. #include <sys/stat.h>
  38. #include <sys/time.h>
  39. #include <sys/un.h>
  40. #include <arpa/inet.h>
  41. #include <netinet/in.h>
  42. #include <netinet/tcp.h>
  43. #include <assert.h>
  44. #include <err.h>
  45. #include <errno.h>
  46. #include <fcntl.h>
  47. #include <libgen.h>
  48. #include <libutil.h>
  49. #include <paths.h>
  50. #include <pthread.h>
  51. #include <signal.h>
  52. #include <stdarg.h>
  53. #include <stdio.h>
  54. #include <stdlib.h>
  55. #include <stdint.h>
  56. #include <string.h>
  57. #include <syslog.h>
  58. #include <unistd.h>
  59. #include "ggate.h"
  60. #define GGATED_EXPORT_FILE "/etc/gg.exports"
  61. struct ggd_connection {
  62. off_t c_mediasize;
  63. unsigned c_sectorsize;
  64. unsigned c_flags; /* flags (RO/RW) */
  65. int c_diskfd;
  66. int c_sendfd;
  67. int c_recvfd;
  68. time_t c_birthtime;
  69. char *c_path;
  70. uint64_t c_token;
  71. in_addr_t c_srcip;
  72. LIST_ENTRY(ggd_connection) c_next;
  73. };
  74. struct ggd_request {
  75. struct g_gate_hdr r_hdr;
  76. char *r_data;
  77. TAILQ_ENTRY(ggd_request) r_next;
  78. };
  79. #define r_cmd r_hdr.gh_cmd
  80. #define r_offset r_hdr.gh_offset
  81. #define r_length r_hdr.gh_length
  82. #define r_error r_hdr.gh_error
  83. struct ggd_export {
  84. char *e_path; /* path to device/file */
  85. in_addr_t e_ip; /* remote IP address */
  86. in_addr_t e_mask; /* IP mask */
  87. unsigned e_flags; /* flags (RO/RW) */
  88. SLIST_ENTRY(ggd_export) e_next;
  89. };
  90. static long niothreads = 20;
  91. static const char *exports_file = GGATED_EXPORT_FILE;
  92. static int got_sighup = 0;
  93. static TAILQ_HEAD(, ggd_request) inqueue = TAILQ_HEAD_INITIALIZER(inqueue);
  94. static TAILQ_HEAD(, ggd_request) outqueue = TAILQ_HEAD_INITIALIZER(outqueue);
  95. static pthread_mutex_t inqueue_mtx, outqueue_mtx;
  96. static pthread_cond_t inqueue_cond, outqueue_cond;
  97. static SLIST_HEAD(, ggd_export) exports = SLIST_HEAD_INITIALIZER(exports);
  98. static LIST_HEAD(, ggd_connection) connections = LIST_HEAD_INITIALIZER(connections);
  99. static void *recv_thread(void *arg);
  100. static void *disk_thread(void *arg);
  101. static void *send_thread(void *arg);
  102. static void
  103. usage(void)
  104. {
  105. fprintf(stderr, "usage: %s [-nv] [-a address] [-F pidfile] [-p port] "
  106. "[-R rcvbuf] [-S sndbuf] [-s socket] [exports file]\n", getprogname());
  107. exit(EXIT_FAILURE);
  108. }
  109. static char *
  110. ip2str(in_addr_t ip)
  111. {
  112. static char sip[16];
  113. snprintf(sip, sizeof(sip), "%u.%u.%u.%u",
  114. ((ip >> 24) & 0xff),
  115. ((ip >> 16) & 0xff),
  116. ((ip >> 8) & 0xff),
  117. (ip & 0xff));
  118. return (sip);
  119. }
  120. static in_addr_t
  121. countmask(unsigned m)
  122. {
  123. in_addr_t mask;
  124. if (m == 0) {
  125. mask = 0x0;
  126. } else {
  127. mask = 1 << (32 - m);
  128. mask--;
  129. mask = ~mask;
  130. }
  131. return (mask);
  132. }
  133. static void
  134. line_parse(char *line, unsigned lineno)
  135. {
  136. struct ggd_export *ex;
  137. char *word, *path, *sflags;
  138. unsigned flags, i, vmask;
  139. in_addr_t ip, mask;
  140. ip = mask = flags = vmask = 0;
  141. path = NULL;
  142. sflags = NULL;
  143. for (i = 0, word = strtok(line, " \t"); word != NULL;
  144. i++, word = strtok(NULL, " \t")) {
  145. switch (i) {
  146. case 0: /* IP address or host name */
  147. ip = g_gate_str2ip(strsep(&word, "/"));
  148. if (ip == INADDR_NONE) {
  149. g_gate_xlog("Invalid IP/host name at line %u.",
  150. lineno);
  151. }
  152. ip = ntohl(ip);
  153. if (word == NULL)
  154. vmask = 32;
  155. else {
  156. errno = 0;
  157. vmask = strtoul(word, NULL, 10);
  158. if (vmask == 0 && errno != 0) {
  159. g_gate_xlog("Invalid IP mask value at "
  160. "line %u.", lineno);
  161. }
  162. if ((unsigned)vmask > 32) {
  163. g_gate_xlog("Invalid IP mask value at line %u.",
  164. lineno);
  165. }
  166. }
  167. mask = countmask(vmask);
  168. break;
  169. case 1: /* flags */
  170. if (strcasecmp("rd", word) == 0 ||
  171. strcasecmp("ro", word) == 0) {
  172. flags = O_RDONLY;
  173. } else if (strcasecmp("wo", word) == 0) {
  174. flags = O_WRONLY;
  175. } else if (strcasecmp("rw", word) == 0) {
  176. flags = O_RDWR;
  177. } else {
  178. g_gate_xlog("Invalid value in flags field at "
  179. "line %u.", lineno);
  180. }
  181. sflags = word;
  182. break;
  183. case 2: /* path */
  184. if (strlen(word) >= MAXPATHLEN) {
  185. g_gate_xlog("Path too long at line %u. ",
  186. lineno);
  187. }
  188. path = word;
  189. break;
  190. default:
  191. g_gate_xlog("Too many arguments at line %u. ", lineno);
  192. }
  193. }
  194. if (i != 3)
  195. g_gate_xlog("Too few arguments at line %u.", lineno);
  196. ex = malloc(sizeof(*ex));
  197. if (ex == NULL)
  198. g_gate_xlog("Not enough memory.");
  199. ex->e_path = strdup(path);
  200. if (ex->e_path == NULL)
  201. g_gate_xlog("Not enough memory.");
  202. /* Made 'and' here. */
  203. ex->e_ip = (ip & mask);
  204. ex->e_mask = mask;
  205. ex->e_flags = flags;
  206. SLIST_INSERT_HEAD(&exports, ex, e_next);
  207. g_gate_log(LOG_DEBUG, "Added %s/%u %s %s to exports list.",
  208. ip2str(ex->e_ip), vmask, path, sflags);
  209. }
  210. static void
  211. exports_clear(void)
  212. {
  213. struct ggd_export *ex;
  214. while (!SLIST_EMPTY(&exports)) {
  215. ex = SLIST_FIRST(&exports);
  216. SLIST_REMOVE_HEAD(&exports, e_next);
  217. free(ex);
  218. }
  219. }
  220. #define EXPORTS_LINE_SIZE 2048
  221. static void
  222. exports_get(void)
  223. {
  224. char buf[EXPORTS_LINE_SIZE], *line;
  225. unsigned lineno = 0, objs = 0, len;
  226. FILE *fd;
  227. exports_clear();
  228. fd = fopen(exports_file, "r");
  229. if (fd == NULL) {
  230. g_gate_xlog("Cannot open exports file (%s): %s.", exports_file,
  231. strerror(errno));
  232. }
  233. g_gate_log(LOG_INFO, "Reading exports file (%s).", exports_file);
  234. for (;;) {
  235. if (fgets(buf, sizeof(buf), fd) == NULL) {
  236. if (feof(fd))
  237. break;
  238. g_gate_xlog("Error while reading exports file: %s.",
  239. strerror(errno));
  240. }
  241. /* Increase line count. */
  242. lineno++;
  243. /* Skip spaces and tabs. */
  244. for (line = buf; *line == ' ' || *line == '\t'; ++line)
  245. ;
  246. /* Empty line, comment or empty line at the end of file. */
  247. if (*line == '\n' || *line == '#' || *line == '\0')
  248. continue;
  249. len = strlen(line);
  250. if (line[len - 1] == '\n') {
  251. /* Remove new line char. */
  252. line[len - 1] = '\0';
  253. } else {
  254. if (!feof(fd))
  255. g_gate_xlog("Line %u too long.", lineno);
  256. }
  257. line_parse(line, lineno);
  258. objs++;
  259. }
  260. fclose(fd);
  261. if (objs == 0)
  262. g_gate_xlog("There are no objects to export.");
  263. g_gate_log(LOG_INFO, "Exporting %u object(s).", objs);
  264. }
  265. static int
  266. exports_check(struct ggd_export *ex, struct g_gate_cinit *cinit,
  267. struct ggd_connection *conn)
  268. {
  269. char ipmask[32]; /* 32 == strlen("xxx.xxx.xxx.xxx/xxx.xxx.xxx.xxx")+1 */
  270. int error = 0, flags;
  271. strlcpy(ipmask, ip2str(ex->e_ip), sizeof(ipmask));
  272. strlcat(ipmask, "/", sizeof(ipmask));
  273. strlcat(ipmask, ip2str(ex->e_mask), sizeof(ipmask));
  274. if ((cinit->gc_flags & GGATE_FLAG_RDONLY) != 0) {
  275. if (ex->e_flags == O_WRONLY) {
  276. g_gate_log(LOG_WARNING, "Read-only access requested, "
  277. "but %s (%s) is exported write-only.", ex->e_path,
  278. ipmask);
  279. return (EPERM);
  280. } else {
  281. conn->c_flags |= GGATE_FLAG_RDONLY;
  282. }
  283. } else if ((cinit->gc_flags & GGATE_FLAG_WRONLY) != 0) {
  284. if (ex->e_flags == O_RDONLY) {
  285. g_gate_log(LOG_WARNING, "Write-only access requested, "
  286. "but %s (%s) is exported read-only.", ex->e_path,
  287. ipmask);
  288. return (EPERM);
  289. } else {
  290. conn->c_flags |= GGATE_FLAG_WRONLY;
  291. }
  292. } else {
  293. if (ex->e_flags == O_RDONLY) {
  294. g_gate_log(LOG_WARNING, "Read-write access requested, "
  295. "but %s (%s) is exported read-only.", ex->e_path,
  296. ipmask);
  297. return (EPERM);
  298. } else if (ex->e_flags == O_WRONLY) {
  299. g_gate_log(LOG_WARNING, "Read-write access requested, "
  300. "but %s (%s) is exported write-only.", ex->e_path,
  301. ipmask);
  302. return (EPERM);
  303. }
  304. }
  305. if ((conn->c_flags & GGATE_FLAG_RDONLY) != 0)
  306. flags = O_RDONLY;
  307. else if ((conn->c_flags & GGATE_FLAG_WRONLY) != 0)
  308. flags = O_WRONLY;
  309. else
  310. flags = O_RDWR;
  311. conn->c_diskfd = open(ex->e_path, flags);
  312. if (conn->c_diskfd == -1) {
  313. error = errno;
  314. g_gate_log(LOG_ERR, "Cannot open %s: %s.", ex->e_path,
  315. strerror(error));
  316. return (error);
  317. }
  318. return (0);
  319. }
  320. static struct ggd_export *
  321. exports_find(struct sockaddr *s, struct g_gate_cinit *cinit,
  322. struct ggd_connection *conn)
  323. {
  324. struct ggd_export *ex;
  325. in_addr_t ip;
  326. int error;
  327. ip = htonl(((struct sockaddr_in *)(void *)s)->sin_addr.s_addr);
  328. SLIST_FOREACH(ex, &exports, e_next) {
  329. if ((ip & ex->e_mask) != ex->e_ip) {
  330. g_gate_log(LOG_DEBUG, "exports[%s]: IP mismatch.",
  331. ex->e_path);
  332. continue;
  333. }
  334. if (strcmp(cinit->gc_path, ex->e_path) != 0) {
  335. g_gate_log(LOG_DEBUG, "exports[%s]: Path mismatch.",
  336. ex->e_path);
  337. continue;
  338. }
  339. error = exports_check(ex, cinit, conn);
  340. if (error == 0)
  341. return (ex);
  342. else {
  343. errno = error;
  344. return (NULL);
  345. }
  346. }
  347. g_gate_log(LOG_WARNING, "Unauthorized connection from: %s.",
  348. ip2str(ip));
  349. errno = EPERM;
  350. return (NULL);
  351. }
  352. /*
  353. * Remove timed out connections.
  354. */
  355. static void
  356. connection_cleanups(void)
  357. {
  358. struct ggd_connection *conn, *tconn;
  359. time_t now;
  360. time(&now);
  361. LIST_FOREACH_SAFE(conn, &connections, c_next, tconn) {
  362. if (now - conn->c_birthtime > 10) {
  363. LIST_REMOVE(conn, c_next);
  364. g_gate_log(LOG_NOTICE,
  365. "Connection from %s [%s] removed.",
  366. ip2str(conn->c_srcip), conn->c_path);
  367. close(conn->c_diskfd);
  368. close(conn->c_sendfd);
  369. close(conn->c_recvfd);
  370. free(conn->c_path);
  371. free(conn);
  372. }
  373. }
  374. }
  375. static struct ggd_connection *
  376. connection_find(struct g_gate_cinit *cinit)
  377. {
  378. struct ggd_connection *conn;
  379. LIST_FOREACH(conn, &connections, c_next) {
  380. if (conn->c_token == cinit->gc_token)
  381. break;
  382. }
  383. return (conn);
  384. }
  385. static struct ggd_connection *
  386. connection_new(struct g_gate_cinit *cinit, struct sockaddr *s, int sfd)
  387. {
  388. struct ggd_connection *conn;
  389. in_addr_t ip;
  390. /*
  391. * First, look for old connections.
  392. * We probably should do it every X seconds, but what for?
  393. * It is only dangerous if an attacker wants to overload connections
  394. * queue, so here is a good place to do the cleanups.
  395. */
  396. connection_cleanups();
  397. conn = malloc(sizeof(*conn));
  398. if (conn == NULL)
  399. return (NULL);
  400. conn->c_path = strdup(cinit->gc_path);
  401. if (conn->c_path == NULL) {
  402. free(conn);
  403. return (NULL);
  404. }
  405. conn->c_token = cinit->gc_token;
  406. ip = htonl(((struct sockaddr_in *)(void *)s)->sin_addr.s_addr);
  407. conn->c_srcip = ip;
  408. conn->c_sendfd = conn->c_recvfd = -1;
  409. if ((cinit->gc_flags & GGATE_FLAG_SEND) != 0)
  410. conn->c_sendfd = sfd;
  411. else
  412. conn->c_recvfd = sfd;
  413. conn->c_mediasize = 0;
  414. conn->c_sectorsize = 0;
  415. time(&conn->c_birthtime);
  416. conn->c_flags = cinit->gc_flags;
  417. LIST_INSERT_HEAD(&connections, conn, c_next);
  418. g_gate_log(LOG_DEBUG, "Connection created [%s, %s].", ip2str(ip),
  419. conn->c_path);
  420. return (conn);
  421. }
  422. static int
  423. connection_add(struct ggd_connection *conn, struct g_gate_cinit *cinit,
  424. struct sockaddr *s, int sfd)
  425. {
  426. in_addr_t ip;
  427. ip = htonl(((struct sockaddr_in *)(void *)s)->sin_addr.s_addr);
  428. if ((cinit->gc_flags & GGATE_FLAG_SEND) != 0) {
  429. if (conn->c_sendfd != -1) {
  430. g_gate_log(LOG_WARNING,
  431. "Send socket already exists [%s, %s].", ip2str(ip),
  432. conn->c_path);
  433. return (EEXIST);
  434. }
  435. conn->c_sendfd = sfd;
  436. } else {
  437. if (conn->c_recvfd != -1) {
  438. g_gate_log(LOG_WARNING,
  439. "Receive socket already exists [%s, %s].",
  440. ip2str(ip), conn->c_path);
  441. return (EEXIST);
  442. }
  443. conn->c_recvfd = sfd;
  444. }
  445. g_gate_log(LOG_DEBUG, "Connection added [%s, %s].", ip2str(ip),
  446. conn->c_path);
  447. return (0);
  448. }
  449. /*
  450. * Remove one socket from the given connection or the whole
  451. * connection if sfd == -1.
  452. */
  453. static void
  454. connection_remove(struct ggd_connection *conn)
  455. {
  456. LIST_REMOVE(conn, c_next);
  457. g_gate_log(LOG_DEBUG, "Connection removed [%s %s].",
  458. ip2str(conn->c_srcip), conn->c_path);
  459. if (conn->c_sendfd != -1)
  460. close(conn->c_sendfd);
  461. if (conn->c_recvfd != -1)
  462. close(conn->c_recvfd);
  463. free(conn->c_path);
  464. free(conn);
  465. }
  466. static int
  467. connection_ready(struct ggd_connection *conn)
  468. {
  469. return (conn->c_sendfd != -1 && conn->c_recvfd != -1);
  470. }
  471. static void
  472. connection_launch(struct ggd_connection *conn)
  473. {
  474. pthread_t td;
  475. int error, pid;
  476. int i;
  477. pid = fork();
  478. if (pid > 0)
  479. return;
  480. else if (pid == -1) {
  481. g_gate_log(LOG_ERR, "Cannot fork: %s.", strerror(errno));
  482. return;
  483. }
  484. g_gate_log(LOG_DEBUG, "Process created [%s], pid: %d.", conn->c_path, getpid());
  485. /*
  486. * Create condition variables and mutexes for in-queue and out-queue
  487. * synchronization.
  488. */
  489. error = pthread_mutex_init(&inqueue_mtx, NULL);
  490. if (error != 0) {
  491. g_gate_xlog("pthread_mutex_init(inqueue_mtx): %s.",
  492. strerror(error));
  493. }
  494. error = pthread_cond_init(&inqueue_cond, NULL);
  495. if (error != 0) {
  496. g_gate_xlog("pthread_cond_init(inqueue_cond): %s.",
  497. strerror(error));
  498. }
  499. error = pthread_mutex_init(&outqueue_mtx, NULL);
  500. if (error != 0) {
  501. g_gate_xlog("pthread_mutex_init(outqueue_mtx): %s.",
  502. strerror(error));
  503. }
  504. error = pthread_cond_init(&outqueue_cond, NULL);
  505. if (error != 0) {
  506. g_gate_xlog("pthread_cond_init(outqueue_cond): %s.",
  507. strerror(error));
  508. }
  509. /*
  510. * Create threads:
  511. * recvtd - thread for receiving I/O request
  512. * diskio - thread for doing I/O request
  513. * sendtd - thread for sending I/O requests back
  514. */
  515. error = pthread_create(&td, NULL, send_thread, conn);
  516. if (error != 0) {
  517. g_gate_xlog("pthread_create(send_thread): %s.",
  518. strerror(error));
  519. }
  520. error = pthread_create(&td, NULL, recv_thread, conn);
  521. if (error != 0) {
  522. g_gate_xlog("pthread_create(recv_thread): %s.",
  523. strerror(error));
  524. }
  525. for (i = 0; niothreads && i < niothreads - 1; i++) {
  526. error = pthread_create(&td, NULL, disk_thread, conn);
  527. if (error != 0) {
  528. g_gate_xlog("pthread_create(disk_thread): %s.",
  529. strerror(error));
  530. }
  531. }
  532. disk_thread(conn);
  533. }
  534. static void
  535. sendfail(int sfd, int error, const char *fmt, ...)
  536. {
  537. struct g_gate_sinit sinit;
  538. va_list ap;
  539. ssize_t data;
  540. memset(&sinit, 0, sizeof(sinit));
  541. sinit.gs_error = error;
  542. g_gate_swap2n_sinit(&sinit);
  543. data = g_gate_send(sfd, &sinit, sizeof(sinit), 0);
  544. g_gate_swap2h_sinit(&sinit);
  545. if (data != sizeof(sinit)) {
  546. g_gate_log(LOG_WARNING, "Cannot send initial packet: %s.",
  547. strerror(errno));
  548. return;
  549. }
  550. if (fmt != NULL) {
  551. va_start(ap, fmt);
  552. g_gate_vlog(LOG_WARNING, fmt, ap);
  553. va_end(ap);
  554. }
  555. }
  556. static void *
  557. malloc_waitok(size_t size)
  558. {
  559. void *p;
  560. while ((p = malloc(size)) == NULL) {
  561. g_gate_log(LOG_DEBUG, "Cannot allocate %zu bytes.", size);
  562. sleep(1);
  563. }
  564. return (p);
  565. }
  566. static void *
  567. recv_thread(void *arg)
  568. {
  569. struct ggd_connection *conn;
  570. struct ggd_request *req;
  571. ssize_t data;
  572. int error, fd;
  573. conn = arg;
  574. g_gate_log(LOG_NOTICE, "%s: started [%s]!", __func__, conn->c_path);
  575. fd = conn->c_recvfd;
  576. for (;;) {
  577. /*
  578. * Get header packet.
  579. */
  580. req = malloc_waitok(sizeof(*req));
  581. data = g_gate_recv(fd, &req->r_hdr, sizeof(req->r_hdr),
  582. MSG_WAITALL);
  583. if (data == 0) {
  584. g_gate_log(LOG_DEBUG, "Process %u exiting.", getpid());
  585. exit(EXIT_SUCCESS);
  586. } else if (data == -1) {
  587. g_gate_xlog("Error while receiving hdr packet: %s.",
  588. strerror(errno));
  589. } else if (data != sizeof(req->r_hdr)) {
  590. g_gate_xlog("Malformed hdr packet received.");
  591. }
  592. g_gate_log(LOG_DEBUG, "Received hdr packet.");
  593. g_gate_swap2h_hdr(&req->r_hdr);
  594. g_gate_log(LOG_DEBUG, "%s: offset=%jd length=%u", __func__,
  595. (intmax_t)req->r_offset, (unsigned)req->r_length);
  596. /*
  597. * Allocate memory for data.
  598. */
  599. req->r_data = malloc_waitok(req->r_length);
  600. /*
  601. * Receive data to write for WRITE request.
  602. */
  603. if (req->r_cmd == GGATE_CMD_WRITE) {
  604. g_gate_log(LOG_DEBUG, "Waiting for %u bytes of data...",
  605. req->r_length);
  606. data = g_gate_recv(fd, req->r_data, req->r_length,
  607. MSG_WAITALL);
  608. if (data == -1) {
  609. g_gate_xlog("Error while receiving data: %s.",
  610. strerror(errno));
  611. }
  612. }
  613. /*
  614. * Put the request onto the incoming queue.
  615. */
  616. error = pthread_mutex_lock(&inqueue_mtx);
  617. assert(error == 0);
  618. TAILQ_INSERT_TAIL(&inqueue, req, r_next);
  619. error = pthread_cond_signal(&inqueue_cond);
  620. assert(error == 0);
  621. error = pthread_mutex_unlock(&inqueue_mtx);
  622. assert(error == 0);
  623. }
  624. }
  625. static void *
  626. disk_thread(void *arg)
  627. {
  628. struct ggd_connection *conn;
  629. struct ggd_request *req;
  630. ssize_t data;
  631. int error, fd;
  632. conn = arg;
  633. g_gate_log(LOG_NOTICE, "%s: started [%s]!", __func__, conn->c_path);
  634. fd = conn->c_diskfd;
  635. for (;;) {
  636. /*
  637. * Get a request from the incoming queue.
  638. */
  639. error = pthread_mutex_lock(&inqueue_mtx);
  640. assert(error == 0);
  641. while ((req = TAILQ_FIRST(&inqueue)) == NULL) {
  642. error = pthread_cond_wait(&inqueue_cond, &inqueue_mtx);
  643. assert(error == 0);
  644. }
  645. TAILQ_REMOVE(&inqueue, req, r_next);
  646. error = pthread_mutex_unlock(&inqueue_mtx);
  647. assert(error == 0);
  648. /*
  649. * Check the request.
  650. */
  651. assert(req->r_cmd == GGATE_CMD_READ || req->r_cmd == GGATE_CMD_WRITE || req->r_cmd == GGATE_CMD_DELETE || req->r_cmd == GGATE_CMD_FLUSH);
  652. assert(req->r_offset + req->r_length <= (uintmax_t)conn->c_mediasize);
  653. assert((req->r_offset % conn->c_sectorsize) == 0);
  654. assert((req->r_length % conn->c_sectorsize) == 0);
  655. g_gate_log(LOG_DEBUG, "%s: offset=%jd length=%u", __func__,
  656. (intmax_t)req->r_offset, (unsigned)req->r_length);
  657. /*
  658. * Do the request.
  659. */
  660. data = 0;
  661. switch (req->r_cmd) {
  662. case GGATE_CMD_READ:
  663. data = pread(fd, req->r_data, req->r_length,
  664. req->r_offset);
  665. break;
  666. case GGATE_CMD_WRITE:
  667. data = pwrite(fd, req->r_data, req->r_length,
  668. req->r_offset);
  669. /* Free data memory here - better sooner. */
  670. free(req->r_data);
  671. req->r_data = NULL;
  672. break;
  673. case GGATE_CMD_DELETE:
  674. case GGATE_CMD_FLUSH:
  675. /* do nothing for now */
  676. break;
  677. }
  678. if (data != (ssize_t)req->r_length) {
  679. /* Report short reads/writes as I/O errors. */
  680. if (errno == 0)
  681. errno = EIO;
  682. g_gate_log(LOG_ERR, "Disk error: %s", strerror(errno));
  683. req->r_error = errno;
  684. if (req->r_data != NULL) {
  685. free(req->r_data);
  686. req->r_data = NULL;
  687. }
  688. }
  689. /*
  690. * Put the request onto the outgoing queue.
  691. */
  692. error = pthread_mutex_lock(&outqueue_mtx);
  693. assert(error == 0);
  694. TAILQ_INSERT_TAIL(&outqueue, req, r_next);
  695. error = pthread_cond_signal(&outqueue_cond);
  696. assert(error == 0);
  697. error = pthread_mutex_unlock(&outqueue_mtx);
  698. assert(error == 0);
  699. }
  700. /* NOTREACHED */
  701. return (NULL);
  702. }
  703. static void *
  704. send_thread(void *arg)
  705. {
  706. struct ggd_connection *conn;
  707. struct ggd_request *req;
  708. ssize_t data;
  709. int error, fd;
  710. conn = arg;
  711. g_gate_log(LOG_NOTICE, "%s: started [%s]!", __func__, conn->c_path);
  712. fd = conn->c_sendfd;
  713. for (;;) {
  714. /*
  715. * Get a request from the outgoing queue.
  716. */
  717. error = pthread_mutex_lock(&outqueue_mtx);
  718. assert(error == 0);
  719. while ((req = TAILQ_FIRST(&outqueue)) == NULL) {
  720. error = pthread_cond_wait(&outqueue_cond,
  721. &outqueue_mtx);
  722. assert(error == 0);
  723. }
  724. TAILQ_REMOVE(&outqueue, req, r_next);
  725. error = pthread_mutex_unlock(&outqueue_mtx);
  726. assert(error == 0);
  727. g_gate_log(LOG_DEBUG, "%s: offset=%jd length=%u", __func__,
  728. (intmax_t)req->r_offset, (unsigned)req->r_length);
  729. /*
  730. * Send the request.
  731. */
  732. g_gate_swap2n_hdr(&req->r_hdr);
  733. if (g_gate_send(fd, &req->r_hdr, sizeof(req->r_hdr), 0) == -1) {
  734. g_gate_xlog("Error while sending hdr packet: %s.",
  735. strerror(errno));
  736. }
  737. g_gate_log(LOG_DEBUG, "Sent hdr packet.");
  738. g_gate_swap2h_hdr(&req->r_hdr);
  739. if (req->r_data != NULL) {
  740. data = g_gate_send(fd, req->r_data, req->r_length, 0);
  741. if (data != (ssize_t)req->r_length) {
  742. g_gate_xlog("Error while sending data: %s.",
  743. strerror(errno));
  744. }
  745. g_gate_log(LOG_DEBUG,
  746. "Sent %zd bytes (offset=%ju, size=%zu).", data,
  747. (uintmax_t)req->r_offset, (size_t)req->r_length);
  748. free(req->r_data);
  749. }
  750. free(req);
  751. }
  752. /* NOTREACHED */
  753. return (NULL);
  754. }
  755. static void
  756. log_connection(struct sockaddr *from)
  757. {
  758. in_addr_t ip;
  759. ip = htonl(((struct sockaddr_in *)(void *)from)->sin_addr.s_addr);
  760. g_gate_log(LOG_INFO, "Connection from: %s.", ip2str(ip));
  761. }
  762. static int
  763. handshake(struct sockaddr *from, int sfd)
  764. {
  765. struct g_gate_version ver;
  766. struct g_gate_cinit cinit;
  767. struct g_gate_sinit sinit;
  768. struct ggd_connection *conn;
  769. struct ggd_export *ex;
  770. ssize_t data;
  771. log_connection(from);
  772. /*
  773. * Phase 1: Version verification.
  774. */
  775. g_gate_log(LOG_DEBUG, "Receiving version packet.");
  776. data = g_gate_recv(sfd, &ver, sizeof(ver), MSG_WAITALL);
  777. g_gate_swap2h_version(&ver);
  778. if (data != sizeof(ver)) {
  779. g_gate_log(LOG_WARNING, "Malformed version packet.");
  780. return (0);
  781. }
  782. g_gate_log(LOG_DEBUG, "Version packet received.");
  783. if (memcmp(ver.gv_magic, GGATE_MAGIC, strlen(GGATE_MAGIC)) != 0) {
  784. g_gate_log(LOG_WARNING, "Invalid magic field.");
  785. return (0);
  786. }
  787. if (ver.gv_version != GGATE_VERSION) {
  788. g_gate_log(LOG_WARNING, "Version %u is not supported.",
  789. ver.gv_version);
  790. return (0);
  791. }
  792. ver.gv_error = 0;
  793. g_gate_swap2n_version(&ver);
  794. data = g_gate_send(sfd, &ver, sizeof(ver), 0);
  795. g_gate_swap2h_version(&ver);
  796. if (data == -1) {
  797. sendfail(sfd, errno, "Error while sending version packet: %s.",
  798. strerror(errno));
  799. return (0);
  800. }
  801. /*
  802. * Phase 2: Request verification.
  803. */
  804. g_gate_log(LOG_DEBUG, "Receiving initial packet.");
  805. data = g_gate_recv(sfd, &cinit, sizeof(cinit), MSG_WAITALL);
  806. g_gate_swap2h_cinit(&cinit);
  807. if (data != sizeof(cinit)) {
  808. g_gate_log(LOG_WARNING, "Malformed initial packet.");
  809. return (0);
  810. }
  811. g_gate_log(LOG_DEBUG, "Initial packet received.");
  812. conn = connection_find(&cinit);
  813. if (conn != NULL) {
  814. /*
  815. * Connection should already exists.
  816. */
  817. g_gate_log(LOG_DEBUG, "Found existing connection (token=%lu).",
  818. (unsigned long)conn->c_token);
  819. if (connection_add(conn, &cinit, from, sfd) == -1) {
  820. connection_remove(conn);
  821. return (0);
  822. }
  823. } else {
  824. /*
  825. * New connection, allocate space.
  826. */
  827. conn = connection_new(&cinit, from, sfd);
  828. if (conn == NULL) {
  829. sendfail(sfd, ENOMEM,
  830. "Cannot allocate new connection.");
  831. return (0);
  832. }
  833. g_gate_log(LOG_DEBUG, "New connection created (token=%lu).",
  834. (unsigned long)conn->c_token);
  835. }
  836. ex = exports_find(from, &cinit, conn);
  837. if (ex == NULL) {
  838. sendfail(sfd, errno, NULL);
  839. connection_remove(conn);
  840. return (0);
  841. }
  842. if (conn->c_mediasize == 0) {
  843. conn->c_mediasize = g_gate_mediasize(conn->c_diskfd);
  844. conn->c_sectorsize = g_gate_sectorsize(conn->c_diskfd);
  845. }
  846. sinit.gs_mediasize = conn->c_mediasize;
  847. sinit.gs_sectorsize = conn->c_sectorsize;
  848. sinit.gs_error = 0;
  849. g_gate_log(LOG_DEBUG, "Sending initial packet.");
  850. g_gate_swap2n_sinit(&sinit);
  851. data = g_gate_send(sfd, &sinit, sizeof(sinit), 0);
  852. g_gate_swap2h_sinit(&sinit);
  853. if (data == -1) {
  854. sendfail(sfd, errno, "Error while sending initial packet: %s.",
  855. strerror(errno));
  856. return (0);
  857. }
  858. if (connection_ready(conn)) {
  859. connection_launch(conn);
  860. connection_remove(conn);
  861. }
  862. return (1);
  863. }
  864. static void
  865. huphandler(int sig __unused)
  866. {
  867. got_sighup = 1;
  868. }
  869. /*
  870. * If sockaddr is not NULL, bind to the Unix domain socket at sockname,
  871. * otherwise bind to the INET addr:port
  872. */
  873. static int
  874. bindsocket(in_addr_t bindaddr, int port, char *sockname)
  875. {
  876. struct sockaddr_un unixaddr;
  877. struct sockaddr_in serv;
  878. int sfd;
  879. g_gate_log(LOG_INFO, "binding socket");
  880. if (sockname != NULL) {
  881. if (strlen(sockname) + 1 > sizeof(unixaddr.sun_path))
  882. g_gate_xlog("Socket path is too long.");
  883. sfd = socket(AF_UNIX, SOCK_STREAM, 0);
  884. if (sfd == -1)
  885. g_gate_xlog("Cannot open stream socket: %s.", strerror(errno));
  886. unixaddr = (struct sockaddr_un) {
  887. .sun_len = sizeof(unixaddr),
  888. .sun_family = AF_UNIX,
  889. };
  890. strncpy(unixaddr.sun_path, sockname, sizeof(unixaddr.sun_path));
  891. if (bind(sfd, (struct sockaddr *)&unixaddr, sizeof(unixaddr)) == -1)
  892. g_gate_xlog("bind(): %s.", strerror(errno));
  893. if (listen(sfd, 5) == -1)
  894. g_gate_xlog("listen(): %s.", strerror(errno));
  895. g_gate_log(LOG_INFO, "Listen on path: %s.", sockname);
  896. } else {
  897. sfd = socket(AF_INET, SOCK_STREAM, 0);
  898. if (sfd == -1)
  899. g_gate_xlog("Cannot open stream socket: %s.", strerror(errno));
  900. bzero(&serv, sizeof(serv));
  901. serv.sin_family = AF_INET;
  902. serv.sin_addr.s_addr = bindaddr;
  903. serv.sin_port = htons(port);
  904. g_gate_socket_settings(sfd);
  905. if (bind(sfd, (struct sockaddr *)&serv, sizeof(serv)) == -1)
  906. g_gate_xlog("bind(): %s.", strerror(errno));
  907. if (listen(sfd, 5) == -1)
  908. g_gate_xlog("listen(): %s.", strerror(errno));
  909. g_gate_log(LOG_INFO, "Listen on port: %d.", port);
  910. }
  911. return sfd;
  912. }
  913. int
  914. main(int argc, char *argv[])
  915. {
  916. const char *ggated_pidfile = _PATH_VARRUN "/ggated.pid";
  917. char *sockname = NULL;
  918. struct pidfh *pfh;
  919. struct sockaddr from;
  920. socklen_t fromlen;
  921. in_addr_t bindaddr;
  922. pid_t otherpid;
  923. int ch, sfd, tmpsfd;
  924. unsigned port;
  925. bindaddr = htonl(INADDR_ANY);
  926. port = G_GATE_PORT;
  927. while ((ch = getopt(argc, argv, "a:hnp:q:F:R:S:s:v")) != -1) {
  928. switch (ch) {
  929. case 'a':
  930. bindaddr = g_gate_str2ip(optarg);
  931. if (bindaddr == INADDR_NONE) {
  932. errx(EXIT_FAILURE,
  933. "Invalid IP/host name to bind to.");
  934. }
  935. break;
  936. case 'F':
  937. ggated_pidfile = optarg;
  938. break;
  939. case 'n':
  940. nagle = 0;
  941. break;
  942. case 'p':
  943. errno = 0;
  944. port = strtoul(optarg, NULL, 10);
  945. if (port == 0 && errno != 0)
  946. errx(EXIT_FAILURE, "Invalid port.");
  947. break;
  948. case 'q':
  949. niothreads = strtol(optarg, NULL, 10);
  950. if (niothreads <= 0)
  951. errx(EXIT_FAILURE, "Invalid queue size.");
  952. break;
  953. case 'R':
  954. errno = 0;
  955. rcvbuf = strtoul(optarg, NULL, 10);
  956. if (rcvbuf == 0 && errno != 0)
  957. errx(EXIT_FAILURE, "Invalid rcvbuf.");
  958. break;
  959. case 'S':
  960. errno = 0;
  961. sndbuf = strtoul(optarg, NULL, 10);
  962. if (sndbuf == 0 && errno != 0)
  963. errx(EXIT_FAILURE, "Invalid sndbuf.");
  964. break;
  965. case 's':
  966. sockname = strdup(optarg);
  967. break;
  968. case 'v':
  969. g_gate_verbose++;
  970. break;
  971. case 'h':
  972. default:
  973. usage();
  974. }
  975. }
  976. argc -= optind;
  977. argv += optind;
  978. if (argv[0] != NULL)
  979. exports_file = argv[0];
  980. exports_get();
  981. pfh = pidfile_open(ggated_pidfile, 0600, &otherpid);
  982. if (pfh == NULL) {
  983. if (errno == EEXIST) {
  984. errx(EXIT_FAILURE, "Daemon already running, pid: %jd.",
  985. (intmax_t)otherpid);
  986. }
  987. err(EXIT_FAILURE, "Cannot open/create pidfile");
  988. }
  989. signal(SIGCHLD, SIG_IGN);
  990. sfd = bindsocket(bindaddr, port, sockname);
  991. if (!g_gate_verbose) {
  992. FILE *t = fopen("local.log", "w");
  993. /* Run in daemon mode. */
  994. if (daemon(0, 0) == -1)
  995. g_gate_xlog("Cannot daemonize: %s", strerror(errno));
  996. stderr = t;
  997. }
  998. pidfile_write(pfh);
  999. signal(SIGHUP, huphandler);
  1000. for (;;) {
  1001. fromlen = sizeof(from);
  1002. tmpsfd = accept(sfd, &from, &fromlen);
  1003. if (tmpsfd == -1)
  1004. g_gate_xlog("accept(): %s.", strerror(errno));
  1005. if (got_sighup) {
  1006. got_sighup = 0;
  1007. exports_get();
  1008. }
  1009. if (!handshake(&from, tmpsfd))
  1010. close(tmpsfd);
  1011. }
  1012. close(sfd);
  1013. pidfile_remove(pfh);
  1014. exit(EXIT_SUCCESS);
  1015. }