Menu
▾
▴
aprsd-devel
|
From: Bruno Q. <que...@ve...> - 2001-08-09 19:27:15
|
Hi to all,
I've seen on the wish list sent on the list that to have a seperate
serial module would be a desirable thing.
I've got a module that is mainly based on the current 2.1.4 serial
module but with small modification as notes in the following :
- Support for multiple serial port
- Configuration file includes device file, serial speed and
seperate conf file per port
- Single thread per defined serial port that can be opened on
the machine
- Connects throught TCP/IP on a special port
-This server thread would need to add directly to history.
- Identification of the packets to which interface it came
from
I'm also working on the server side to support this type of
connection. Could also use the current password/username conbination
that is currenly in use. The packets could be tagged using the socket
it came from so that is retransmission is needed (gate2rf, etc).
I would like some comments on this subject, just to see if I make
sense and if still worth while to code and is of interest from the
group. This "module" could permit coverage to different region and bring
the data to "bigger" server that could have bigger pipes and/or bigger
muscle poer....
--
Bruno Quesnel que...@cn...
Canadian National Railways que...@ve...
Analyste reseau - Network analyst VA2BMG
|
|
From: Hamish M. <ha...@cl...> - 2001-08-09 22:21:47
|
On Thu, Aug 09, 2001 at 03:27:03PM -0400, Bruno Quesnel wrote: > I've seen on the wish list sent on the list that to have a seperate > serial module would be a desirable thing. > > I've got a module that is mainly based on the current 2.1.4 serial > module but with small modification as notes in the following : > > - Support for multiple serial port I think it would be better to run one port-handler per port, with each connected to a single aprsd. It would make the program simpler. > - Connects throught TCP/IP on a special port > -This server thread would need to add directly to history. > - Identification of the packets to which interface it came > from I agree, this is necessary. Also, please incorporate the current RF interface (rf.h/cpp, sockets.h/cpp, serial.h/cpp), not the old serial-only interface. Sockets is a mainstream aprsd feature now that we're working in CVS and must be supported. regards Hamish -- Hamish Moffatt VK3SB <ha...@de...> <ha...@cl...> |
|
From: Bruno Q. <que...@ve...> - 2001-08-10 00:58:08
|
Hamish Moffatt wrote: > On Thu, Aug 09, 2001 at 03:27:03PM -0400, Bruno Quesnel wrote: > > I've seen on the wish list sent on the list that to have a seperate > > serial module would be a desirable thing. > > > > I've got a module that is mainly based on the current 2.1.4 serial > > module but with small modification as notes in the following : > > > > - Support for multiple serial port > > I think it would be better to run one port-handler per port, with each > connected to a single aprsd. It would make the program simpler. > I don't understand, It is threaded based on the number of ports defined in the config file, which all thread connect to one server also defined in the config file. > > > - Connects throught TCP/IP on a special port > > -This server thread would need to add directly to history. > > - Identification of the packets to which interface it came > > from > > I agree, this is necessary. > > Also, please incorporate the current RF interface (rf.h/cpp, sockets.h/cpp, > serial.h/cpp), not the old serial-only interface. Sockets is a mainstream > aprsd feature now that we're working in CVS and must be supported. > Will do. Sockets was the way to go... no doubt in my mind. > > regards > Hamish > -- > Hamish Moffatt VK3SB <ha...@de...> <ha...@cl...> > > _______________________________________________ > Aprsd-devel mailing list > Apr...@li... > http://lists.sourceforge.net/lists/listinfo/aprsd-devel -- Bruno Quesnel va...@vi... Genie Electrique que...@ve... Electrical Engineering VA2BMG Ecole de Technologies Superieure http://www.findu.com/cgi-bin/find.cgi?va2bmg |
|
From: Hamish M. <ha...@cl...> - 2001-08-10 02:10:10
|
On Thu, Aug 09, 2001 at 08:59:23PM -0400, Bruno Quesnel wrote: > Hamish Moffatt wrote: > > I think it would be better to run one port-handler per port, with each > > connected to a single aprsd. It would make the program simpler. > > I don't understand, It is threaded based on the number of ports defined in the > config file, which all thread connect to one server also defined in the config > file. That makes the port-handler more complicated than it needs to be. Multiple instances of the port-handler is simpler than a single instance with multiple threads. And the port-handlers don't need to share any/much data, so there is no benefit to them beiong multithreaded. Hamish Hamish Moffatt VK3SB <ha...@de...> <ha...@cl...> |
|
From: Bruno Q. <que...@ve...> - 2001-08-10 15:25:55
|
Ok, I think I got it now... Invoke the proper number of a function as per the
number of ports.... Good (if that's what you meant)....
I have another question :
I was thinking of supporting the feature of sending a signal to the serial
process (SIGHUG) so it would reconfigure itself. The reconfiguration would mainly
concern the addition/removal of serial ports definition. Or also to reconfigure
the use of a port.
My main idea here would be to strip the support for configuring the TNC (in the
case of the TNC is used) in the program itself. So in the config you remove the
serial line for that port, send the signal to the program, then use a terminal
program to change the TNC and then re-enable the line in the program and resend the
signal.
In this case, it would simplify the logic of the reception loop in the serial
module. Please comment!!!!
Also, another question, do we want the serial module to be dumb in the sense
that it would do basic verification on the packet and ship it directly to the
"igate" at the other end which would treat the stream as it comes or put some basic
logic to offer certain logic to answer query.
I guess my question would be that that this module would be just to gatther
information from possible remote site or local sites (no real difference) and make
the igate treat all the information. This would transfer some of the resposibility
on the igate part and make some small modules to get the data where needed. Would
also be easy to support other form of interface to get the data to the network.
(Thinking here of sound card interface that could be used. With small module that
just ship, you only need to implement interface and worry only about the hardware
interface. Then they all would send the data the same way, throught sockets,
whatever the physical interface). To support multiple physical interface and have
a seperate or one module that would worry about the physical interface to get data
accross. More comments please
Hamish Moffatt wrote:
>
> That makes the port-handler more complicated than it needs to be.
> Multiple instances of the port-handler is simpler than a single
> instance with multiple threads. And the port-handlers don't
> need to share any/much data, so there is no benefit to them
> beiong multithreaded.
>
--
Bruno Quesnel que...@cn...
Canadian National Railways que...@ve...
Analyste reseau - Network analyst VA2BMG
|
Thanks for helping keep SourceForge clean.
X