Re: [fpc-pascal] lnet for TCP daemon
On 2013-09-18 09:20, Michael Van Canneyt wrote: > > The fptimer unit implements a timer with a thread, but this forces the use of > threads on your application The way I like it! ;-) Especially considering how thread friendly these [common place] multi-core CPU's are these days. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On Wed, Sep 18, 2013 at 03:57:36PM +0200, Marco van de Voort wrote: > In our previous episode, Henry Vermaak said: > > > > Should be doable, as well. AFAIK, mse (for Linux) uses signals > > > > on that behalf. We might want to steal some ideas there. > > > > > > While there is sigalarm, but can you have multiple independent > > > timers in an application that way? > > > > I think Martin used setitimer and handles multiple timers by > > calculating which one expires first, and subtracting that amount > > from the other timers, etc. > > That's a trick commonly done on embedded platforms with limited timers > (I actually did it once as part of a course that created a small RTOS > for 8051 chips), but on *nix systems where libraries might also > reserve certain itimers, that could fail miserably. Yes, the POSIX interval timers are a much better solution for this. Dealing with signals are still a bit annoying, but things like timerfd and signalfd are linux specific. Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On 09/18/2013 05:03 PM, Sven Barth wrote: TThread.Queue is a rather new addition. Delphi 2009 if I'm correct. So that's definitely not "very early". OK, at least four years ;-) . I have "Turbo Delphi". Here it is implemented but not to be found in the help. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
In our previous episode, Sven Barth said: > > forced to "by hand" use Windows messages to schedule asynchronous Main > > Thread events. > > TThread.Queue is a rather new addition. Delphi 2009 if I'm correct. So > that's definitely not "very early". D2006 afaik. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On 18.09.2013 13:33, Michael Schnell wrote: On 09/18/2013 01:19 PM, Mattias Gaertner wrote: Some users asked about messages from/to other applications for nogui LCL applications on Windows. OK. In fact to me it has been a completely silly concept of Borland's that in early Delphi versions TThread.Queue was not documented (or in very early versions maybe not even implemented) and thus the users were forced to "by hand" use Windows messages to schedule asynchronous Main Thread events. TThread.Queue is a rather new addition. Delphi 2009 if I'm correct. So that's definitely not "very early". Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
In our previous episode, Henry Vermaak said: > > > Should be doable, as well. AFAIK, mse (for Linux) uses signals on that > > > behalf. We might want to steal some ideas there. > > > > While there is sigalarm, but can you have multiple independent timers in an > > application that way? > > I think Martin used setitimer and handles multiple timers by calculating > which one expires first, and subtracting that amount from the other > timers, etc. That's a trick commonly done on embedded platforms with limited timers (I actually did it once as part of a course that created a small RTOS for 8051 chips), but on *nix systems where libraries might also reserve certain itimers, that could fail miserably. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On Wed, 18 Sep 2013, Michael Schnell wrote: On 09/18/2013 01:26 PM, Marco van de Voort wrote: While there is sigalarm, but can you have multiple independent timers in an application that way? I don't know. We would need to ask mse. mse inverts the problem. The timer implementation relies on an external 'tick' routine. How this tick is delivered depends entirely on the event loop. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On Wed, Sep 18, 2013 at 01:26:46PM +0200, Marco van de Voort wrote: > In our previous episode, Michael Schnell said: > > > The fptimer unit implements a timer with a thread, but this forces the > > > use of threads on your application which is not always desirable. > > > > Should be doable, as well. AFAIK, mse (for Linux) uses signals on that > > behalf. We might want to steal some ideas there. > > While there is sigalarm, but can you have multiple independent timers in an > application that way? I think Martin used setitimer and handles multiple timers by calculating which one expires first, and subtracting that amount from the other timers, etc. Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On 09/18/2013 01:26 PM, Marco van de Voort wrote: While there is sigalarm, but can you have multiple independent timers in an application that way? I don't know. We would need to ask mse. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On 09/18/2013 01:19 PM, Mattias Gaertner wrote: Some users asked about messages from/to other applications for nogui LCL applications on Windows. OK. In fact to me it has been a completely silly concept of Borland's that in early Delphi versions TThread.Queue was not documented (or in very early versions maybe not even implemented) and thus the users were forced to "by hand" use Windows messages to schedule asynchronous Main Thread events. By that the concepts of Thread to Mainthread signaling has been mixed with the concept of inter-Application signaling (and even the decently ugly windowish Application to GUI Widget signaling). But this is not your or my fault ;-) . Maybe when implementing PostMessage for Thread to Mainthread signaling for windows OS we could take care of inter application messages. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
In our previous episode, Michael Schnell said: > > The fptimer unit implements a timer with a thread, but this forces the > > use of threads on your application which is not always desirable. > > Should be doable, as well. AFAIK, mse (for Linux) uses signals on that > behalf. We might want to steal some ideas there. While there is sigalarm, but can you have multiple independent timers in an application that way? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On Wed, 18 Sep 2013 10:55:34 +0200 Michael Schnell wrote: > On 09/18/2013 10:38 AM, Mattias Gaertner wrote: > > On Wed, 18 Sep 2013 10:25:43 +0200 > > Michael Schnell wrote: > > > >> What non-GUI events - additionally to the events I mentioned - would be > >> needed for "the whole event system of the LCL" ? > > For example PostMessage can send messages to other applications on > > Windows. > > > Of course this is true but is has noting to do with "the event system of > the LCL". Says who? Some users asked about messages from/to other applications for nogui LCL applications on Windows. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On 09/18/2013 12:05 PM, Luca Olivetti wrote: Perhaps if you spent your time actually using fpc instead of hunting for non-problems ... As already pointed out, I have no intention to do a Project of such kind myself. I am just trying to construct a toolbox to help my colleagues to port their Delphi applications. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
Al 18/09/13 09:32, En/na Michael Schnell ha escrit: > It is really frustrating to see, that this now seems to solves the issue > I am hunting for since some five years. Perhaps if you spent your time actually using fpc instead of hunting for non-problems you'd have realized that this worked five (and more) years ago as it does now. Bye -- Luca ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On 09/18/2013 10:38 AM, Mattias Gaertner wrote: On Wed, 18 Sep 2013 10:25:43 +0200 Michael Schnell wrote: What non-GUI events - additionally to the events I mentioned - would be needed for "the whole event system of the LCL" ? For example PostMessage can send messages to other applications on Windows. Of course this is true but is has noting to do with "the event system of the LCL". -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On Wed, 18 Sep 2013 10:25:43 +0200 Michael Schnell wrote: > On 09/18/2013 10:05 AM, Mattias Gaertner wrote: > > On Wed, 18 Sep 2013 09:32:54 +0200 > > Michael Schnell wrote: > > > >> [...] > >> Instead I was told that I should look at the LCL > >> source code and that "in Windows, the Event queuing mechanism is done by > >> Windows itself and in Linux it is done by a queue in the LCL that is > >> managed by the underlying Widget Set". > > This is true for PostMessage. > > (and supposedly for Application.QueueAsyncCall) No. QueueAsyncCall is implemented in the LCL without widgetset code. >[...] > What non-GUI events - additionally to the events I mentioned - would be > needed for "the whole event system of the LCL" ? For example PostMessage can send messages to other applications on Windows. >[...] I don't need this for any > concrete application, but for creating an "SDK" that allows for porting > existing Delphi applications in a way as easy to use as possible. Really? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On 09/18/2013 10:20 AM, Michael Van Canneyt wrote: The fptimer unit implements a timer with a thread, but this forces the use of threads on your application which is not always desirable. Should be doable, as well. AFAIK, mse (for Linux) uses signals on that behalf. We might want to steal some ideas there. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On 09/18/2013 10:09 AM, Sven Barth wrote: I would not use Sleep as you need to be able to cancel the timer A decent point ... -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On 09/18/2013 10:05 AM, Mattias Gaertner wrote: On Wed, 18 Sep 2013 09:32:54 +0200 Michael Schnell wrote: [...] Instead I was told that I should look at the LCL source code and that "in Windows, the Event queuing mechanism is done by Windows itself and in Linux it is done by a queue in the LCL that is managed by the underlying Widget Set". This is true for PostMessage. (and supposedly for Application.QueueAsyncCall) Of course I do know this and this is what makes it impossible to port the Delphi applications, my colleagues did, to a non-GUI environment. The new idea now is, that implementing PostMessage (and supposedly Application.QueueAsyncCall) might be done using the existing RTL Event queue (which only recently came to my full awareness), instead of creating (or in Windows attaching to) an additional queuing mechanism. There are many ways to implement timers and queues. But if you want the whole event system of the LCL then you need do more. What non-GUI events - additionally to the events I mentioned - would be needed for "the whole event system of the LCL" ? Have you ever asked how to program a timer in a console application on this list? Of course I do know that this is doable (and I already did it several times). But (as I mentioned multiple times) I don't need this for any concrete application, but for creating an "SDK" that allows for porting existing Delphi applications in a way as easy to use as possible. Thus an "Application" and "Postmessage" (thus an LCL Widget Type implementation) is necessary. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On Wed, 18 Sep 2013, Sven Barth wrote: On 18.09.2013 09:32, Michael Schnell wrote: - TTimer is implemented including defining the timeout constant for calls to CheckSynchronize() as the greatest common denominator of the "Time" property of all enabled TTimer instances in the project (i.e. a simple timer that accumulates delays imposed by MainThread activities) I wouldn't use the timeout constant for this. If you have two timers of which the greatest common denominator is 1, but nevertheless rather large (e.g. two primes) then you'd loop unnecessarily (I know this is a constructed example, but nevertheless one should care for this!). I'd instead suggest to implement the timerloop of each timer as a thread that waits its timeout time on a event (so that it can also be stopped) and then notifies the mainthread using Queue(). Preferably, a standard timer implementation does not use a thread at all. The fptimer unit implements a timer with a thread, but this forces the use of threads on your application which is not always desirable. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On 18.09.2013 10:00, Michael Schnell wrote: On 09/18/2013 09:53 AM, Sven Barth wrote: I wouldn't use the timeout constant for this. If you have two timers of which the greatest common denominator is 1, but nevertheless rather large (e.g. two primes) then you'd loop unnecessarily (I know this is a constructed example, but nevertheless one should care for this!). I'd instead suggest to implement the timerloop of each timer as a thread that waits its timeout time on a event (so that it can also be stopped) and then notifies the mainthread using Queue(). Right you are. (I just wanted to keep this as simple as possible for a starter.) You simply could use a sleep in the timer loop,. This would be arch independent out of the box. But it would impose accumulative delays depending on the CPU performance. I would not use Sleep as you need to be able to cancel the timer (e.g. Timer.Enabled := False or the application terminating). At least on *nix based systems you'd need to artificially send a signal which is why I'd prefer the event way which you can simply set in SetEnabled and Free. An more advanced timer implementation would use arch depending OS-based timers. This would allow for a much more exact timing. Of course. The timer component should be written in a way that it can be implemented in a platform specific way as well. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On Wed, 18 Sep 2013 09:32:54 +0200 Michael Schnell wrote: >[...] > It is really frustrating to see, that this now seems to solves the issue > I am hunting for since some five years. Has it ever come to your mind that "hunting" might not be sufficient to create code? > Over the time, there had been > multiple discussions on this, initially in the fpc devel mailing list > and later in the Lazarus devel mailing list. Up till now, I never was > told "this already works" or "this is easy" (followed by a decent > description - such as yours - of CheckSynchronize() See for example: http://lists.lazarus.freepascal.org/pipermail/lazarus/2012-August/075593.html > and > WakeMainThread(). Instead I was told that I should look at the LCL > source code and that "in Windows, the Event queuing mechanism is done by > Windows itself and in Linux it is done by a queue in the LCL that is > managed by the underlying Widget Set". This is true for PostMessage. > This (some years ago) misled me > to invest a considerable amount of time in unsuccessfully trying to > strip off the GUI binding from an existing LCL Widget Type. There are many ways to implement timers and queues. But if you want the whole event system of the LCL then you need do more. Have you ever asked how to program a timer in a console application on this list? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On 09/18/2013 09:53 AM, Sven Barth wrote: I wouldn't use the timeout constant for this. If you have two timers of which the greatest common denominator is 1, but nevertheless rather large (e.g. two primes) then you'd loop unnecessarily (I know this is a constructed example, but nevertheless one should care for this!). I'd instead suggest to implement the timerloop of each timer as a thread that waits its timeout time on a event (so that it can also be stopped) and then notifies the mainthread using Queue(). Right you are. (I just wanted to keep this as simple as possible for a starter.) You simply could use a sleep in the timer loop,. This would be arch independent out of the box. But it would impose accumulative delays depending on the CPU performance. An more advanced timer implementation would use arch depending OS-based timers. This would allow for a much more exact timing. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On 18.09.2013 09:32, Michael Schnell wrote: - TTimer is implemented including defining the timeout constant for calls to CheckSynchronize() as the greatest common denominator of the "Time" property of all enabled TTimer instances in the project (i.e. a simple timer that accumulates delays imposed by MainThread activities) I wouldn't use the timeout constant for this. If you have two timers of which the greatest common denominator is 1, but nevertheless rather large (e.g. two primes) then you'd loop unnecessarily (I know this is a constructed example, but nevertheless one should care for this!). I'd instead suggest to implement the timerloop of each timer as a thread that waits its timeout time on a event (so that it can also be stopped) and then notifies the mainthread using Queue(). Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
Conclusion: Thus we could draft a "living noGUI" TCustomApplication sibling (aka "LCL WidgetType"), that allows for firing MainThread Events triggered from (a newly implemented) TTimer, TThread.Queue(), TThread.Synchronize(), TApplication.QueueAsyncCall() and the legacy windowish PostMessage() -> "procedure..message" mechanism in a low latency and low processor-overhead way: - The Application Object contains a MainLoop simply calling CheckSynchronize() - TTimer is implemented including defining the timeout constant for calls to CheckSynchronize() as the greatest common denominator of the "Time" property of all enabled TTimer instances in the project (i.e. a simple timer that accumulates delays imposed by MainThread activities) - TThread.Queue() and TThread.Synchronize() seemingly just work - TApplication.QueueAsyncCall() and PostMessage() could be implemented using "NotifyMainThread()" (and maybe slightly enhancing the queuing and de-queuing mechanism provided in the RTL for additionally allowing for this type of Events, containing procedure pointer, self-pointer and an Integer that can be pointer to a parameter or holds the Windows-Message parameters. ) This would provide the mechanism for porting "embedded" (thus without GUI - or with the GUI configured as "disabled" at compile time) Delphi applications to non-GUI Linux gadgets. It is really frustrating to see, that this now seems to solves the issue I am hunting for since some five years. Over the time, there had been multiple discussions on this, initially in the fpc devel mailing list and later in the Lazarus devel mailing list. Up till now, I never was told "this already works" or "this is easy" (followed by a decent description - such as yours - of CheckSynchronize() and WakeMainThread(). Instead I was told that I should look at the LCL source code and that "in Windows, the Event queuing mechanism is done by Windows itself and in Linux it is done by a queue in the LCL that is managed by the underlying Widget Set". This (some years ago) misled me to invest a considerable amount of time in unsuccessfully trying to strip off the GUI binding from an existing LCL Widget Type. Unfortunately until end of this year I will am busy with a complicated (non pascal and not even Linux) project and I'll be not able to do some other programming work (and hopefully provide a patch enabling the functionality described above). But If somebody wants we can go on discussing the issue here, at "fpc devel" or at "lazarus devel". Thanks for listening, -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
Thanks for the clear information. Enhanced by the knowledge about TThread.queue It will allow me to do some nice tricks. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On 09/16/2013 02:01 PM, Sven Barth wrote: ( http://www.freepascal.org/docs-html/rtl/classes/wakemainthread.html ). IIRC, TThread.Queue does this, as well. Thus updating this page might be appropriate... Thanks, -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On 09/16/2013 02:01 PM, Sven Barth wrote: WakeMainThread Thanks for the pointer. I'll take another look there. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On 09/16/2013 02:03 PM, Sven Barth wrote: CheckSynchronize has a timeout parameter: http://www.freepascal.org/docs-html/rtl/classes/checksynchronize.html Great ! Maybe the docs should be updated and mention TThread.Queue, which for me is most important, as it - finally - allows for decent parallel work of Worker threads and mainthread in applications that don't use the (GUI binding of the) LCL. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
Am 16.09.2013 13:38, schrieb Michael Schnell: there is no LCL dependence in theory, but other eventloop systems might assume they themselves implement the blocking part. (e.g. to wake up because of OS messages) Services, console network server implementations etc probably already do that both on Delphi and Lazarus. In fact the LCL seems to rely on the "It blocks for a maximum time" (as you said). While this might be "good enough" for GUI events, there might be instances where we either would want either (1) a faster reaction (than the said "maximum time") on events that are not to be pushed through the RTL event queue or (2) avoid the processor overhead that is imposed by the main thread leaving the block after the "maximum time". Regarding (2), I suppose it would be just nice to be able to define this time (I need to check the sources or the docs to find out). CheckSynchronize has a timeout parameter: http://www.freepascal.org/docs-html/rtl/classes/checksynchronize.html Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
Am 16.09.2013 13:22, schrieb Marco van de Voort: Did I understand you correctly that there is a "notifying" procedure, that is called by the Event queuing mechanism each time an event is pushed onto the queue ? That was not me, but Sven or sb else. But as I understood it, the queue method does that internally(thus platform dependent). He never said it was a public option. You trigger it by queue()ing or synchronize()ing. I did not say it explicitely, but meant it that way. See WakeMainThread ( http://www.freepascal.org/docs-html/rtl/classes/wakemainthread.html ). This procedure then would potentially be called from Worker threads and thus here, we need use the OS to schedule the (later to be done) queue poll by the main thread via checksynchronize(). No. The mainthread simply should always loop around checksynchronize while idle. Checksynchronize is the delay in the event loop so to say, by blocking on some internal event. Thus if something is queued, the event is triggered and the mainthread will wake up immediately (if it was indeed blocked on checksynchronize) WakeMainThread is used by the LCL to initiate an idle-event (whatever an "event" is for the underlying widgetset) so that CheckSynchronize gets executed. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
Am 16.09.2013 10:58, schrieb Michael Schnell: On 09/13/2013 07:08 PM, Sven Barth wrote: As we have already written in some previous mails to there is a global event procedure to wake up the main thread that is triggered when something is queued. The LCL uses this already and other programs could use a TEvent or whatever. Could you elaborate on this ? Is this "triggering" done by some kind of self-piping or using an OS semaphore ? Is it provided for all OSes and Archs Or do you mean a function call is provided that allows the user (or the LCL) to implement such a functionality. The latter: http://www.freepascal.org/docs-html/rtl/classes/wakemainthread.html It is called by the internal procedure ThreadQueueAppend which is used by both TThread.Queue and TThread.Synchronize. Additionally if the the main thread is already waiting inside a CheckSynchronize() call it is notified using an event. Regads, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On 09/16/2013 01:22 PM, Marco van de Voort wrote: The non-LCL one must simply call checksynchronize as the blocking part of the mainthread's eventloop. Thus, my wish already seems to be fulfilled. Great ! there is no LCL dependence in theory, but other eventloop systems might assume they themselves implement the blocking part. (e.g. to wake up because of OS messages) Services, console network server implementations etc probably already do that both on Delphi and Lazarus. In fact the LCL seems to rely on the "It blocks for a maximum time" (as you said). While this might be "good enough" for GUI events, there might be instances where we either would want either (1) a faster reaction (than the said "maximum time") on events that are not to be pushed through the RTL event queue or (2) avoid the processor overhead that is imposed by the main thread leaving the block after the "maximum time". Regarding (2), I suppose it would be just nice to be able to define this time (I need to check the sources or the docs to find out). Regarding (1), I suppose this will be a really rare request (not even required by my foreseeable queer projects). I would rather do this kind of stuff in worker threads and use TThread.Queue (which hurray !!! is available since some time) to schedule main thread actions. Thanks a lot ! -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
In our previous episode, Michael Schnell said: > OK, so "checksynchronize()" is the correct name of the RTL-provided > function that pulls the event queue. (Sorry that the correct name > escaped from my silly brain.) Yes, it is the connection between VCL and RTL for this kind of stuff. > AFAIU this supposedly is not platform-dependent, but simply pulls the > queue and calls the event handlers as sub-functions of checksynchronize(). > (I need to check the sources ASAP...) It blocks for a maximum time on the event. > Did I understand you correctly that there is a "notifying" procedure, > that is called by the Event queuing mechanism each time an event is > pushed onto the queue ? That was not me, but Sven or sb else. But as I understood it, the queue method does that internally(thus platform dependent). He never said it was a public option. You trigger it by queue()ing or synchronize()ing. > This procedure then would potentially be called from Worker threads and > thus here, we need use the OS to schedule the (later to be done) queue > poll by the main thread via checksynchronize(). No. The mainthread simply should always loop around checksynchronize while idle. Checksynchronize is the delay in the event loop so to say, by blocking on some internal event. Thus if something is queued, the event is triggered and the mainthread will wake up immediately (if it was indeed blocked on checksynchronize) > Obviously the LCL needs to use both procedures to merge the RTL's event > queue with the queue it handles the GUI events in. > Obviously a non-LCL based user code can implement it's own OS-depending > mechanism to schedule a call to checksynchronize() triggered by the said > "notifying" procedure. The non-LCL one must simply call checksynchronize as the blocking part of the mainthread's eventloop. > The "hope" I expressed in the recent mail was, that the RTL might allow > for enabling the described OS-depending Thread to MainThread scheduling > mechanism, so that any user code does not need to implement it new with > each project (but just set an enable flag or something similar). See above. It is there, there is no LCL dependence in theory, but other eventloop systems might assume they themselves implement the blocking part. (e.g. to wake up because of OS messages) Services, console network server implementations etc probably already do that both on Delphi and Lazarus. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On 09/16/2013 11:14 AM, Marco van de Voort wrote: If you mean integrate with your own eventloop, then yes, make sure that your idle event in your eventloop calls checksyncrhonize OK, so "checksynchronize()" is the correct name of the RTL-provided function that pulls the event queue. (Sorry that the correct name escaped from my silly brain.) AFAIU this supposedly is not platform-dependent, but simply pulls the queue and calls the event handlers as sub-functions of checksynchronize(). (I need to check the sources ASAP...) Did I understand you correctly that there is a "notifying" procedure, that is called by the Event queuing mechanism each time an event is pushed onto the queue ? This procedure then would potentially be called from Worker threads and thus here, we need use the OS to schedule the (later to be done) queue poll by the main thread via checksynchronize(). Could you tell me the name of that procedure, so that I can find it in the sources and do a testing project using it ? Obviously the LCL needs to use both procedures to merge the RTL's event queue with the queue it handles the GUI events in. Obviously a non-LCL based user code can implement it's own OS-depending mechanism to schedule a call to checksynchronize() triggered by the said "notifying" procedure. The "hope" I expressed in the recent mail was, that the RTL might allow for enabling the described OS-depending Thread to MainThread scheduling mechanism, so that any user code does not need to implement it new with each project (but just set an enable flag or something similar). This should be possible as the RTL does know which OS it is built for and the maintainers do have the necessary expertize to do it in the optimum way. Thanks, -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
In our previous episode, Michael Schnell said: > > As we have already written in some previous mails to there is a global > > event procedure to wake up the main thread that is triggered when > > something is queued. The LCL uses this already and other programs > > could use a TEvent or whatever. > > Could you elaborate on this ? Is this "triggering" done by some kind of > self-piping or using an OS semaphore ? Is it provided for all OSes and Archs Afaik it is implemented in the checksynchronize call in a platform dependent manner. It assumes that you run checksynchronize in the idle event of your eventloop though. (which should be the case for LCL implementations) > Or do you mean a function call is provided that allows the user (or the > LCL) to implement such a functionality. If you mean integrate with your own eventloop, then yes, make sure that your idle event in your eventloop calls checksyncrhonize. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On 09/13/2013 07:08 PM, Sven Barth wrote: As we have already written in some previous mails to there is a global event procedure to wake up the main thread that is triggered when something is queued. The LCL uses this already and other programs could use a TEvent or whatever. Could you elaborate on this ? Is this "triggering" done by some kind of self-piping or using an OS semaphore ? Is it provided for all OSes and Archs Or do you mean a function call is provided that allows the user (or the LCL) to implement such a functionality. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
Am 13.09.2013 10:47 schrieb "Michael Schnell" : > > On 09/13/2013 06:06 AM, wkitt...@windstream.net wrote: >> >> would this hamper or cause problems with normal non-gui programs using the library? > > > 1) This feature of course should only be provided additionally to the functions we know and love. > > 2) Other than the work-alike "Application.QueueAsyncCall" which is provided by Lazarus long since, the rather new "TThread.Queue" is not only Delphi-compatible, but it also is located in the RTL and thus can be used in LCL based nongui applications and even without linking to the LCL at all. > > You need to do calls to a "synchronize" function which the RTL provides, to pull the event queue. This _can_ be done in a close loop (e.g. containing a sleep() call), which of course increases latency and processor overhead. Better it is done by a decent triggering mechanism (e.g. using a semaphore or self-piping) the loop waits for and each queue push triggers. > > This is another improvement I hope for: enhancing the synchronize and TThread.Queue/TThread.Synchronize features in the RTL in an OS-depending way that (optionally) automatically pulls the queue for the main thread. As we have already written in some previous mails to there is a global event procedure to wake up the main thread that is triggered when something is queued. The LCL uses this already and other programs could use a TEvent or whatever. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On 09/13/2013 06:06 AM, wkitt...@windstream.net wrote: would this hamper or cause problems with normal non-gui programs using the library? 1) This feature of course should only be provided additionally to the functions we know and love. 2) Other than the work-alike "Application.QueueAsyncCall" which is provided by Lazarus long since, the rather new "TThread.Queue" is not only Delphi-compatible, but it also is located in the RTL and thus can be used in LCL based nongui applications and even without linking to the LCL at all. You need to do calls to a "synchronize" function which the RTL provides, to pull the event queue. This _can_ be done in a close loop (e.g. containing a sleep() call), which of course increases latency and processor overhead. Better it is done by a decent triggering mechanism (e.g. using a semaphore or self-piping) the loop waits for and each queue push triggers. This is another improvement I hope for: enhancing the synchronize and TThread.Queue/TThread.Synchronize features in the RTL in an OS-depending way that (optionally) automatically pulls the queue for the main thread. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On Thursday, September 12, 2013 7:14 AM, Michael Schnell wrote: > On 09/12/2013 12:47 PM, Mark Morgan Lloyd wrote: > > > > I've concluded that using a thread is, in fact, preferable > True. > > It's a pity that Synapse and friend (especially SynaSer) does does not > implement internal threads that throw appropriate events in the Main > Thread when something comes in (or an error appears). This is a very > common request, and since the fpc-Team some time ago enabled > TThread.Queue in the RTL, this is doable in a straight forward, > "fpc-ish" way (portable but Delphi compatible). would this hamper or cause problems with normal non-gui programs using the library? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On 09/12/2013 02:45 PM, Marco van de Voort wrote: E.g. TComport only starts an helper thread if you register receive events. If you do not, you can use it in a select/waitformultiple like way in a thread. Sounds good. I'm going to test this ASAP. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
In our previous episode, Michael Schnell said: > > The very reason I use Synapse is that it DOES NOT use threads. > > Synapse is simple to use. Keep it so. > > Of course I don't vote for Synapse always using threads, but to provide > _additional_ functions / objects (maybe units) that work similar to > AsyncPro (TCP/IP and serial streams). Plus maybe more sophisticated > _additional_ objects that in internal threads handle complete protocols > and provide appropriate MainThread events to the user program. E.g. TComport only starts an helper thread if you register receive events. If you do not, you can use it in a select/waitformultiple like way in a thread. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On 09/12/2013 02:36 PM, Mark Morgan Lloyd wrote: Although for certain types of usage being able to get directly to the hardware (or strictly, to the lowest level the OS supports for normal users) is absolutely essential, e.g. if timing information has to be appended to each character or if records of control signal changes have to be inserted. Of course the current functionality of Synapse needs to stay in place as it is. With Delphi, I very often happily used the asynchronous MainThread Events AsyncPro (for TCP/IP and serial data streams) provides. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On 09/12/2013 01:28 PM, Michael Van Canneyt wrote: The very reason I use Synapse is that it DOES NOT use threads. Synapse is simple to use. Keep it so. Of course I don't vote for Synapse always using threads, but to provide _additional_ functions / objects (maybe units) that work similar to AsyncPro (TCP/IP and serial streams). Plus maybe more sophisticated _additional_ objects that in internal threads handle complete protocols and provide appropriate MainThread events to the user program. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
In our previous episode, Mark Morgan Lloyd said: > > common request, and since the fpc-Team some time ago enabled > > TThread.Queue in the RTL, this is doable in a straight forward, > > "fpc-ish" way (portable but Delphi compatible). > > Although for certain types of usage being able to get directly to the > hardware (or strictly, to the lowest level the OS supports for normal > users) is absolutely essential, e.g. if timing information has to be > appended to each character or if records of control signal changes have > to be inserted. True, but that is rarely done, since you would have to disable FIFOs too then, since you usually can't queue such signals (like e.g. BREAK). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
Michael Schnell wrote: On 09/12/2013 12:47 PM, Mark Morgan Lloyd wrote: I've concluded that using a thread is, in fact, preferable True. It's a pity that Synapse and friend (especially SynaSer) does does not implement internal threads that throw appropriate events in the Main Thread when something comes in (or an error appears). This is a very common request, and since the fpc-Team some time ago enabled TThread.Queue in the RTL, this is doable in a straight forward, "fpc-ish" way (portable but Delphi compatible). Although for certain types of usage being able to get directly to the hardware (or strictly, to the lowest level the OS supports for normal users) is absolutely essential, e.g. if timing information has to be appended to each character or if records of control signal changes have to be inserted. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On Thu, 12 Sep 2013, Michael Schnell wrote: On 09/12/2013 12:47 PM, Mark Morgan Lloyd wrote: I've concluded that using a thread is, in fact, preferable True. It's a pity that Synapse and friend (especially SynaSer) does does not implement internal threads that throw appropriate events in the Main Thread when something comes in (or an error appears). This is a very common request, and since the fpc-Team some time ago enabled TThread.Queue in the RTL, this is doable in a straight forward, "fpc-ish" way (portable but Delphi compatible). The very reason I use Synapse is that it DOES NOT use threads. Synapse is simple to use. Keep it so. The way it is now, threads are still an option. If threads are incorporated in the design there is no way to get them out again. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On 09/12/2013 12:47 PM, Mark Morgan Lloyd wrote: I've concluded that using a thread is, in fact, preferable True. It's a pity that Synapse and friend (especially SynaSer) does does not implement internal threads that throw appropriate events in the Main Thread when something comes in (or an error appears). This is a very common request, and since the fpc-Team some time ago enabled TThread.Queue in the RTL, this is doable in a straight forward, "fpc-ish" way (portable but Delphi compatible). -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
Mark Morgan Lloyd wrote: Michael Schnell wrote: On 09/11/2013 07:22 PM, Mark Morgan Lloyd wrote: I'd normally use a thread for this, but I've already got lnet's telnet client running in the program so would rather stick to the same library if possible. AFAIK, Lnet does not do threading internally (as does AsyncPro or - partly - Indy), so if you need to wait for TCP input while doing other things in your program, you need to do your own thread, anyway. [Nod] Works adequately for a telnet-based terminal though. I switched from Lnet to Synapse lately, as same seems to a lot of provide usable protocols. Synapse does not provide internal threads, either. True. Synapse's protocol support is second to none, but in the current case there's really no protocol involved- grab/store data and that's it. If I understand from more Googling etc., lnet server support works by the program first setting up a server socket and applying Listen, then setting up a connection socket and calling Accept() with the server socket (possibly the server socket's handle, and I'm unsure how to get this) as parameter. Both of these would need CallAction calls on a regular basis. I've concluded that using a thread is, in fact, preferable since I don't know how much data will arrive from the far end, how it will be paced, and whether the far end might attempt multiple simultaneous connections. While a polling scheme is OK for the foreground terminal stuff there's too much change that its proliferation will mess up either foreground or background transfer. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
Mark Morgan Lloyd wrote: Is it feasible to use lnet for a simple TCP daemon on Linux, i.e. wait for a connection on a predefined port, read as much data as is available, repeat? And if so, what does the SerSock parameter to Accept() represent? I'd normally use a thread for this, but I've already got lnet's telnet client running in the program so would rather stick to the same library if possible. Mark, I have done that before. Basically, in Lnet, if you have more than 1 LTcp object, you must create your own TEventer and override its CallAction method. Then assume your Ltcp object is myLTCP myLTCP.Eventer := TMyEventer.Create; In my thread.execute repeat myLTCP.Eventer.CallAction until terminated; if you have just one ltcp then just repeat myLtcp.CallAction until terminated I don't know about SerSock. Never used it and seemed have no need for it. Dennis ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
Michael Schnell wrote: On 09/11/2013 07:22 PM, Mark Morgan Lloyd wrote: I'd normally use a thread for this, but I've already got lnet's telnet client running in the program so would rather stick to the same library if possible. AFAIK, Lnet does not do threading internally (as does AsyncPro or - partly - Indy), so if you need to wait for TCP input while doing other things in your program, you need to do your own thread, anyway. [Nod] Works adequately for a telnet-based terminal though. I switched from Lnet to Synapse lately, as same seems to a lot of provide usable protocols. Synapse does not provide internal threads, either. True. Synapse's protocol support is second to none, but in the current case there's really no protocol involved- grab/store data and that's it. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On 09/11/2013 07:22 PM, Mark Morgan Lloyd wrote: I'd normally use a thread for this, but I've already got lnet's telnet client running in the program so would rather stick to the same library if possible. AFAIK, Lnet does not do threading internally (as does AsyncPro or - partly - Indy), so if you need to wait for TCP input while doing other things in your program, you need to do your own thread, anyway. I switched from Lnet to Synapse lately, as same seems to a lot of provide usable protocols. Synapse does not provide internal threads, either. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] lnet for TCP daemon
Is it feasible to use lnet for a simple TCP daemon on Linux, i.e. wait for a connection on a predefined port, read as much data as is available, repeat? And if so, what does the SerSock parameter to Accept() represent? I'd normally use a thread for this, but I've already got lnet's telnet client running in the program so would rather stick to the same library if possible. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Lnet problem. In console mode, cannot have 2 listening socket
I use the console example lserver.pp in LNet and it works fine that way. However, when I modified it to have 2 listening socket (TLTCP) listen one after another , and in the run loop, repeat socket1.CallAction; socket2.CallAction; until Quit1 or Quit2; Only the first socket that listens runs normally,the socket than listen after the first, cannot accept client. I am wondering this non-thread loop of LNet only supports 1 running server socket. Any one has any idea? Dennis ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lNet and TCP packet length
On 04/02/12 14:14, Bernd wrote: 2012/2/4 Bernd: You need a robust way to determine how long your protocol message is, at which byte exactly it ends and the next message begins. The simplest way would probably be if you prepend all your messages with a length field and a checksum field to be sent as the very first bytes of each of your custom protocol messages (also take care of endianness and exactly specify this in your protocol description). Then you can either read as many bytes are available on the stream (if it is less than still needed) or read only as many bytes as are still missing (if equal or more are available), leave the rest of the data in the stream, process the message and trigger the read event again to read what can only be the beginning of the next message. You can also use lNet in blocking mode (which can sometimes make things easier) simply by specifying a timeout value for the socket. Then you can just have a thread looping and trying to read indefinitely, counting received bytes and let it generate your own events on completion of a message instead of using the lNet events which fire on every TCP packet. Many thanks Bernd, for your very helpful reply. The messages already start with a header record, which includes the length, so I'll add a checksum field to that and work along the lines you suggest. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lNet and TCP packet length
2012/2/4 Bernd : > You need a robust way to determine how long your > protocol message is, at which byte exactly it ends and the next > message begins. The simplest way would probably be if you prepend all your messages with a length field and a checksum field to be sent as the very first bytes of each of your custom protocol messages (also take care of endianness and exactly specify this in your protocol description). Then you can either read as many bytes are available on the stream (if it is less than still needed) or read only as many bytes as are still missing (if equal or more are available), leave the rest of the data in the stream, process the message and trigger the read event again to read what can only be the beginning of the next message. You can also use lNet in blocking mode (which can sometimes make things easier) simply by specifying a timeout value for the socket. Then you can just have a thread looping and trying to read indefinitely, counting received bytes and let it generate your own events on completion of a message instead of using the lNet events which fire on every TCP packet. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lNet and TCP packet length
2012/2/1 Malcolm Poole : > Before I set out to implement the procedures to do this myself, can someone > reassure me that this needs to be done and that I am not re-inventing the > wheel? The TCP protocol will transparently split the data into the packets of needed size without user intervention, so the sending site is probably already ok. But on the receiving side (at least with lNet) you will get a separate event for each received packet and have to combine them again, so you need to implement something on top of lNet to buffer and combine the received chunks of data and only process it when one of your protocol messages is complete. You need a robust way to determine how long your protocol message is, at which byte exactly it ends and the next message begins. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] lNet and TCP packet length
I'm working on a client/server project which involves sending SQL commands from server to client and vice versa. I've been using the LTCP component for both the client and the server, which have been working perfectly during testing on the same machine and between different virtual machines, sending and receiving packets of data several thousand bytes in length. However, when connecting over ethernet or the internet there appears to be a packet limit of 1036 bytes and any packets of data larger than this are truncated. I assume this is to do with maximum permissible transport units in the routers forming the connections and I was mistaken in believing that the lNet TCP implementation would take care of breaking the data down into transmissible packets and reassembling them at the destination. Before I set out to implement the procedures to do this myself, can someone reassure me that this needs to be done and that I am not re-inventing the wheel? Malcolm ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] lNet getting the local IP
>> >> I didn't try it, but I see that it tries to connect to google's dns serve= >r, >> so it'd fail miserably if the computer has no internet access. >> >> Bye >> -- >> Luca >> > >I tested, without web access does not work. :o A hard coded address will of course fail if it cannot be reached. The code was an example, you should use it as such. I substituted my router's ip for google's and it works.;) Choose a different address that would not fail in a specific situation. As another example, one could read their /etc/resolve file to get the dns server that is assigned. Brian Winfrey ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lNet getting the local IP
On Thu, 7 Oct 2010 16:00:31 -0700 Brian Winfrey wrote: > Here are the modifications I made in exploring this issue: It works on: - % uname -a FreeBSD host.ipt.ru 9.0-CURRENT FreeBSD 9.0-CURRENT #3 r213198M: Mon Sep 27 15:43:54 MSD 2010 b...@host.ipt.ru:/usr/obj/usr/src/sys/HOST i386 - -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lNet getting the local IP
I don't know if you noticed, but it appears that code has some
depracated properties that should be changed.
Here are the modifications I made in exploring this issue:
program GetPrimaryIpAddress;
{$mode objfpc}
uses
baseunix,
unixtype,
sockets,
SysUtils;
procedure Get(out AddrOut: string);
const
CN_GDNS_ADDR = '127.0.0.1';
CN_GDNS_PORT = 53;
var
sock: longint;
err: longint;
UnixAddr: TInetSockAddr;
HostAddr: TSockAddr;
len: Integer;
begin
err := 0;
sock := fpsocket(AF_INET, SOCK_DGRAM, 0);
assert(sock <> -1);
// changed because previous properties were deprecated
UnixAddr.sin_family := AF_INET;
UnixAddr.sin_port := htons(CN_GDNS_PORT);
UnixAddr.sin_addr := StrToHostAddr(CN_GDNS_ADDR);
if (fpConnect(sock, @UnixAddr, SizeOf(UnixAddr)) = 0) then
begin
try
len := SizeOf(HostAddr);
if (fpgetsockname(sock, @HostAddr, @len) = 0) then
begin
AddrOut := NetAddrToStr(HostAddr.sin_addr);
end
else
begin
err:=socketError;
end;
finally
if (fpclose(sock) <> 0) then
begin
err := socketError;
end;
end;
end
else
begin
err:=socketError;
end;
if (err <> 0) then
begin
// report error
end;
end;
var
strAddr: string;
begin
Get(strAddr);
WriteLn('ip : ',strAddr);
end.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lNet getting the local IP
I think you want to use 127.0.0.1 to return the actual address.
In my case I would
const
CN_GDNS_ADDR = '127.0.0.1';
run the progarm and the output would be 192.168.1.5 as long as there
is an active interface.
On Thu, Oct 7, 2010 at 3:34 PM, silvioprog wrote:
> Hi Brian,
> I tested again, and discovered that's not is necessary a connection to a
> web.
> I changed to 0.0.0.0 and returned 127.0.0.1, perfect! :)
> I will use this function. Thanks very much again. :)
> 2010/10/7 Brian Winfrey
>>
>> >> On 06/10/10 14:27, Felipe Monteiro de Carvalho wrote:
>> >>> Ok, thanks everyone, it seams that I managed to extract a function
>> >>> from Silvio's code which doesn't use Synapse. I only tested in Windows
>> >>> so far:
>> >>>
>> >>> unit chesstcputils;
>> >>>
>> >>> {$mode objfpc}{$H+}
>> >>>
>> >>> interface
>> >>>
>> >>> uses
>> >>> {$IFDEF MSWINDOWS}
>> >>> Winsock,
>> >>> {$ENDIF}
>> >>> Classes, SysUtils;
>> >>>
>> >>> function ChessGetLocalIP(): string;
>> >>>
>> >>> implementation
>> >>>
>> >>> const
>> >>> CFormatIPMask = '%d.%d.%d.%d';
>> >>>
>> >>> function ChessGetLocalIP(): string;
>> >>> var
>> >>> I, VAttempt: Integer;
>> >>> VStrTemp, VSitesToTry: TStringList;
>> >>> {$IFDEF UNIX}
>> >>> VProcess: TProcess;
>> >>> {$ENDIF}
>> >>> {$IFDEF MSWINDOWS}
>> >>> var
>> >>> VWSAData: TWSAData;
>> >>> VHostEnt: PHostEnt;
>> >>> VName: string;
>> >>> {$ENDIF}
>> >>> begin
>> >>> Result := '';
>> >>> {$IFDEF UNIX}
>> >>> VStrTemp := TStringList.Create;
>> >>> VProcess := TProcess.Create(nil);
>> >>> try
>> >>> VProcess.CommandLine :=
>> >>> 'sh -c "ifconfig eth0 | awk ''/inet end/ {print $3}''"';
>> >>
>> >> Yuck. This doesn't work on my system (debian). If you really want the
>> >> least effort, you may have more luck with simply parsing `hostname -I`
>> >> somehow. The right way to do this is with an ioctl, I believe
>> >> (SIOCGIFCONF). Look here:
>> >>
>> >> http://www.kernel.org/doc/man-pages/online/pages/man7/netdevice.7.html
>> >>
>> >> I'm sure there's some code floating around, but it probably means that
>> >> you have to translate some headers :(.
>> >>
>> >> Henry
>> >>
>> > Re: [fpc-pascal] lNet getting the local IP
>> >>
>> >
>> > I found an example for linux on stack overflow that was in c
>> >
>> > http://stackoverflow.com/questions/212528/linux-c-get-the-ip-address-of-local-computer
>> >
>> > - here is a rough translation:
>> >
>> > program GetPrimaryIpAddress;
>> > {$mode objfpc}
>> >
>> > uses
>> > baseunix,
>> > unixtype,
>> > sockets,
>> > SysUtils;
>> >
>> > procedure Get(var buf: array of char; const len: longint);
>> > const
>> > CN_GDNS_ADDR = '8.8.8.8';
>> > CN_GDNS_PORT = 53;
>> > var
>> > s: string;
>> > sock: longint;
>> > err: longint;
>> > HostAddr: TSockAddr;
>> > l: Integer;
>> > UnixAddr: TInetSockAddr;
>> >
>> > begin
>> > err := 0;
>> > Assert(len >= 16);
>> >
>> > sock := fpsocket(AF_INET, SOCK_DGRAM, 0);
>> > assert(sock <> -1);
>> >
>> > UnixAddr.family := AF_INET;
>> > UnixAddr.port := htons(CN_GDNS_PORT);
>> > UnixAddr.addr := StrToHostAddr(CN_GDNS_ADDR).s_addr;
>> >
>> > if (fpConnect(sock,@UnixAddr,SizeOf(UnixAddr)) = 0) then
>> > begin
>> > try
>> > l := SizeOf(HostAddr);
>> > if (fpgetsockname(sock, @HostAddr, @l) = 0) then
>> > begin
>> > s := NetAddrToStr(HostAddr.sin_addr);
>> > StrPCopy(PChar(Buf), s);
>> > end
>> > else
>> > begin
>> > err:=socketError;
>> > end;
>> > finally
>> > if (fpclose(sock) <> 0) then
>> > begin
>> > err := socketError;
>> > end;
>> > end;
>> > end
>> > else
>> > begin
>> > err:=socketError;
>> > end;
>> >
>> > if (err <> 0) then
>> > begin
>> > // report error
>> > end;
>> > end;
>> >
>> > var
>> > ipbuf: array[0..255] of char;
>> >
>> > begin
>> > system.FillChar(ipbuf, sizeOf(ipBuf), #0);
>> > Get(ipbuf, system.SizeOf(ipbuf));
>> > WriteLn(StrPas(ipbuf));
>> > end.
>> >
>> > BrianW
>> >
>> I have tried this code with multiple scenarios.
>>
>> if interfaces are down, no ip address is returned. I would say that is
>> expected as there is no network.
>> ifconfig will return same. only lo has an address 127.0.0.1.
>>
>> Otherwise I get the primary ip address as long as routing is used.
>>
>> if connecting to 0.0.0.0, 127.0.0.1 is returned
>>
>> Use 127.0.0.1 and the primary is returned.
>>
>> Run some tests and let me know what you find.
>
> --
> Silvio Clécio,
> programmer ObjectPascal
>
>
> ___
> fpc-pascal maillist - fpc-pas...@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lNet getting the local IP
Hi Brian,
I tested again, and discovered that's not is necessary a connection to a
web.
I changed to 0.0.0.0 and returned 127.0.0.1, perfect! :)
I will use this function. Thanks very much again. :)
2010/10/7 Brian Winfrey
> >> On 06/10/10 14:27, Felipe Monteiro de Carvalho wrote:
> >>> Ok, thanks everyone, it seams that I managed to extract a function
> >>> from Silvio's code which doesn't use Synapse. I only tested in Windows
> >>> so far:
> >>>
> >>> unit chesstcputils;
> >>>
> >>> {$mode objfpc}{$H+}
> >>>
> >>> interface
> >>>
> >>> uses
> >>>{$IFDEF MSWINDOWS}
> >>>Winsock,
> >>>{$ENDIF}
> >>>Classes, SysUtils;
> >>>
> >>> function ChessGetLocalIP(): string;
> >>>
> >>> implementation
> >>>
> >>> const
> >>>CFormatIPMask = '%d.%d.%d.%d';
> >>>
> >>> function ChessGetLocalIP(): string;
> >>> var
> >>>I, VAttempt: Integer;
> >>>VStrTemp, VSitesToTry: TStringList;
> >>> {$IFDEF UNIX}
> >>>VProcess: TProcess;
> >>> {$ENDIF}
> >>> {$IFDEF MSWINDOWS}
> >>> var
> >>>VWSAData: TWSAData;
> >>>VHostEnt: PHostEnt;
> >>>VName: string;
> >>> {$ENDIF}
> >>> begin
> >>>Result := '';
> >>> {$IFDEF UNIX}
> >>>VStrTemp := TStringList.Create;
> >>>VProcess := TProcess.Create(nil);
> >>>try
> >>> VProcess.CommandLine :=
> >>> 'sh -c "ifconfig eth0 | awk ''/inet end/ {print $3}''"';
> >>
> >> Yuck. This doesn't work on my system (debian). If you really want the
> >> least effort, you may have more luck with simply parsing `hostname -I`
> >> somehow. The right way to do this is with an ioctl, I believe
> >> (SIOCGIFCONF). Look here:
> >>
> >> http://www.kernel.org/doc/man-pages/online/pages/man7/netdevice.7.html
> >>
> >> I'm sure there's some code floating around, but it probably means that
> >> you have to translate some headers :(.
> >>
> >> Henry
> >>
> > Re: [fpc-pascal] lNet getting the local IP
> >>
> >
> > I found an example for linux on stack overflow that was in c
> >
> http://stackoverflow.com/questions/212528/linux-c-get-the-ip-address-of-local-computer
> >
> > - here is a rough translation:
> >
> > program GetPrimaryIpAddress;
> > {$mode objfpc}
> >
> > uses
> > baseunix,
> > unixtype,
> > sockets,
> > SysUtils;
> >
> > procedure Get(var buf: array of char; const len: longint);
> > const
> > CN_GDNS_ADDR = '8.8.8.8';
> > CN_GDNS_PORT = 53;
> > var
> > s: string;
> > sock: longint;
> > err: longint;
> > HostAddr: TSockAddr;
> > l: Integer;
> > UnixAddr: TInetSockAddr;
> >
> > begin
> > err := 0;
> > Assert(len >= 16);
> >
> > sock := fpsocket(AF_INET, SOCK_DGRAM, 0);
> > assert(sock <> -1);
> >
> > UnixAddr.family := AF_INET;
> > UnixAddr.port := htons(CN_GDNS_PORT);
> > UnixAddr.addr := StrToHostAddr(CN_GDNS_ADDR).s_addr;
> >
> > if (fpConnect(sock,@UnixAddr,SizeOf(UnixAddr)) = 0) then
> > begin
> >try
> > l := SizeOf(HostAddr);
> > if (fpgetsockname(sock, @HostAddr, @l) = 0) then
> > begin
> >s := NetAddrToStr(HostAddr.sin_addr);
> >StrPCopy(PChar(Buf), s);
> > end
> > else
> > begin
> >err:=socketError;
> > end;
> >finally
> > if (fpclose(sock) <> 0) then
> > begin
> >err := socketError;
> > end;
> >end;
> > end
> > else
> > begin
> >err:=socketError;
> > end;
> >
> > if (err <> 0) then
> > begin
> >// report error
> > end;
> > end;
> >
> > var
> > ipbuf: array[0..255] of char;
> >
> > begin
> > system.FillChar(ipbuf, sizeOf(ipBuf), #0);
> > Get(ipbuf, system.SizeOf(ipbuf));
> > WriteLn(StrPas(ipbuf));
> > end.
> >
> > BrianW
> >
> I have tried this code with multiple scenarios.
>
> if interfaces are down, no ip address is returned. I would say that is
> expected as there is no network.
> ifconfig will return same. only lo has an address 127.0.0.1.
>
> Otherwise I get the primary ip address as long as routing is used.
>
> if connecting to 0.0.0.0, 127.0.0.1 is returned
>
> Use 127.0.0.1 and the primary is returned.
>
> Run some tests and let me know what you find.
--
Silvio Clécio,
*programmer* *ObjectPascal*
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lNet getting the local IP
>> On 06/10/10 14:27, Felipe Monteiro de Carvalho wrote:
>>> Ok, thanks everyone, it seams that I managed to extract a function
>>> from Silvio's code which doesn't use Synapse. I only tested in Windows
>>> so far:
>>>
>>> unit chesstcputils;
>>>
>>> {$mode objfpc}{$H+}
>>>
>>> interface
>>>
>>> uses
>>> {$IFDEF MSWINDOWS}
>>> Winsock,
>>> {$ENDIF}
>>> Classes, SysUtils;
>>>
>>> function ChessGetLocalIP(): string;
>>>
>>> implementation
>>>
>>> const
>>> CFormatIPMask = '%d.%d.%d.%d';
>>>
>>> function ChessGetLocalIP(): string;
>>> var
>>> I, VAttempt: Integer;
>>> VStrTemp, VSitesToTry: TStringList;
>>> {$IFDEF UNIX}
>>> VProcess: TProcess;
>>> {$ENDIF}
>>> {$IFDEF MSWINDOWS}
>>> var
>>> VWSAData: TWSAData;
>>> VHostEnt: PHostEnt;
>>> VName: string;
>>> {$ENDIF}
>>> begin
>>> Result := '';
>>> {$IFDEF UNIX}
>>> VStrTemp := TStringList.Create;
>>> VProcess := TProcess.Create(nil);
>>> try
>>> VProcess.CommandLine :=
>>> 'sh -c "ifconfig eth0 | awk ''/inet end/ {print $3}''"';
>>
>> Yuck. This doesn't work on my system (debian). If you really want the
>> least effort, you may have more luck with simply parsing `hostname -I`
>> somehow. The right way to do this is with an ioctl, I believe
>> (SIOCGIFCONF). Look here:
>>
>> http://www.kernel.org/doc/man-pages/online/pages/man7/netdevice.7.html
>>
>> I'm sure there's some code floating around, but it probably means that
>> you have to translate some headers :(.
>>
>> Henry
>>
> Re: [fpc-pascal] lNet getting the local IP
>>
>
> I found an example for linux on stack overflow that was in c
> http://stackoverflow.com/questions/212528/linux-c-get-the-ip-address-of-local-computer
>
> - here is a rough translation:
>
> program GetPrimaryIpAddress;
> {$mode objfpc}
>
> uses
> baseunix,
> unixtype,
> sockets,
> SysUtils;
>
> procedure Get(var buf: array of char; const len: longint);
> const
> CN_GDNS_ADDR = '8.8.8.8';
> CN_GDNS_PORT = 53;
> var
> s: string;
> sock: longint;
> err: longint;
> HostAddr: TSockAddr;
> l: Integer;
> UnixAddr: TInetSockAddr;
>
> begin
> err := 0;
> Assert(len >= 16);
>
> sock := fpsocket(AF_INET, SOCK_DGRAM, 0);
> assert(sock <> -1);
>
> UnixAddr.family := AF_INET;
> UnixAddr.port := htons(CN_GDNS_PORT);
> UnixAddr.addr := StrToHostAddr(CN_GDNS_ADDR).s_addr;
>
> if (fpConnect(sock,@UnixAddr,SizeOf(UnixAddr)) = 0) then
> begin
> try
> l := SizeOf(HostAddr);
> if (fpgetsockname(sock, @HostAddr, @l) = 0) then
> begin
> s := NetAddrToStr(HostAddr.sin_addr);
> StrPCopy(PChar(Buf), s);
> end
> else
> begin
> err:=socketError;
> end;
> finally
> if (fpclose(sock) <> 0) then
> begin
> err := socketError;
> end;
> end;
> end
> else
> begin
> err:=socketError;
> end;
>
> if (err <> 0) then
> begin
> // report error
> end;
> end;
>
> var
> ipbuf: array[0..255] of char;
>
> begin
> system.FillChar(ipbuf, sizeOf(ipBuf), #0);
> Get(ipbuf, system.SizeOf(ipbuf));
> WriteLn(StrPas(ipbuf));
> end.
>
> BrianW
>
I have tried this code with multiple scenarios.
if interfaces are down, no ip address is returned. I would say that is
expected as there is no network.
ifconfig will return same. only lo has an address 127.0.0.1.
Otherwise I get the primary ip address as long as routing is used.
if connecting to 0.0.0.0, 127.0.0.1 is returned
Use 127.0.0.1 and the primary is returned.
Run some tests and let me know what you find.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lNet getting the local IP
I am developing for an embedded system and found out that 'nmap --iflist' does a faily good job of this if the output is examined and parsed properly. If it is suitable and you can possibly extract the code (if you are prepared to go that far) it might help you. It is also cross platform On 7 October 2010 17:58, silvioprog wrote: > 2010/10/7 Luca Olivetti > > >> I didn't try it, but I see that it tries to connect to google's dns >> server, so it'd fail miserably if the computer has no internet access. >> >> Bye >> -- >> Luca >> > > I tested, without web access does not work. :o > > -- > Silvio Clécio, > *programmer* *ObjectPascal* > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > -- Frank Church === http://devblog.brahmancreations.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lNet getting the local IP
2010/10/7 Luca Olivetti > > I didn't try it, but I see that it tries to connect to google's dns server, > so it'd fail miserably if the computer has no internet access. > > Bye > -- > Luca > I tested, without web access does not work. :o -- Silvio Clécio, *programmer* *ObjectPascal* ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] lNet getting the local IP
Choose a different address that would not fail in a specific situation. For example, one could read their /etc/resolve file to get the dns server. Brian Winfrey ~~ Important Note: Code provide as an example. There could be errors or risks in using it. There is no warranty implied or implicit, it may not even work. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lNet getting the local IP
En/na Marco van de Voort ha escrit: In our previous episode, Brian Winfrey said: I found an example for linux on stack overflow that was in c http://stackoverflow.com/questions/212528/linux-c-get-the-ip-address-of-local-computer Compiles on FreeBSD and the result looks sane (but on a system that has a routable address) I didn't try it, but I see that it tries to connect to google's dns server, so it'd fail miserably if the computer has no internet access. Bye -- Luca ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lNet getting the local IP
Wow, worked perfectely in Ubuntu-10.04, Mandriva-2010 and openSUSE-11.2.
Thanks for the exelent solutions. :)
2010/10/7 Brian Winfrey
>
> I found an example for linux on stack overflow that was in c
>
> http://stackoverflow.com/questions/212528/linux-c-get-the-ip-address-of-local-computer
>
> - here is a rough translation:
>
> program GetPrimaryIpAddress;
> {$mode objfpc}
>
> uses
> baseunix,
> unixtype,
> sockets,
> SysUtils;
>
> procedure Get(var buf: array of char; const len: longint);
> const
> CN_GDNS_ADDR = '8.8.8.8';
> CN_GDNS_PORT = 53;
> var
> s: string;
> sock: longint;
> err: longint;
> HostAddr: TSockAddr;
> l: Integer;
> UnixAddr: TInetSockAddr;
>
> begin
> err := 0;
> Assert(len >= 16);
>
> sock := fpsocket(AF_INET, SOCK_DGRAM, 0);
> assert(sock <> -1);
>
> UnixAddr.family := AF_INET;
> UnixAddr.port := htons(CN_GDNS_PORT);
> UnixAddr.addr := StrToHostAddr(CN_GDNS_ADDR).s_addr;
>
> if (fpConnect(sock,@UnixAddr,SizeOf(UnixAddr)) = 0) then
> begin
>try
> l := SizeOf(HostAddr);
> if (fpgetsockname(sock, @HostAddr, @l) = 0) then
> begin
>s := NetAddrToStr(HostAddr.sin_addr);
>StrPCopy(PChar(Buf), s);
> end
> else
> begin
>err:=socketError;
> end;
>finally
> if (fpclose(sock) <> 0) then
> begin
>err := socketError;
> end;
>end;
> end
> else
> begin
>err:=socketError;
> end;
>
> if (err <> 0) then
> begin
>// report error
> end;
> end;
>
> var
> ipbuf: array[0..255] of char;
>
> begin
> system.FillChar(ipbuf, sizeOf(ipBuf), #0);
> Get(ipbuf, system.SizeOf(ipbuf));
> WriteLn(StrPas(ipbuf));
> end.
>
> BrianW
--
Silvio Clécio,
*programmer* *ObjectPascal*
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lNet getting the local IP
In our previous episode, Brian Winfrey said: > I found an example for linux on stack overflow that was in c > http://stackoverflow.com/questions/212528/linux-c-get-the-ip-address-of-local-computer Compiles on FreeBSD and the result looks sane (but on a system that has a routable address) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lNet getting the local IP
On Wed, Oct 6, 2010 at 7:09 AM, wrote: > Send fpc-pascal mailing list submissions to > fpc-pas...@lists.freepascal.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > or, via email, send a message with subject or body 'help' to > fpc-pascal-requ...@lists.freepascal.org > > You can reach the person managing the list at > fpc-pascal-ow...@lists.freepascal.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of fpc-pascal digest..." > > > Today's Topics: > > 1. Re: GetTempFileName in Linux (Michael Van Canneyt) > 2. Re: GetTempFileName in Linux (Jonas Maebe) > 3. Re: lNet getting the local IP (Andrew Brunner) > 4. Re: lNet getting the local IP (Sven Barth) > 5. Re: lNet getting the local IP (Felipe Monteiro de Carvalho) > 6. Re: lNet getting the local IP (Andrew Brunner) > 7. Re: lNet getting the local IP (Marco van de Voort) > 8. Re: lNet getting the local IP (Henry Vermaak) > > > -- > > Message: 1 > Date: Wed, 6 Oct 2010 11:59:53 +0200 (CEST) > From: Michael Van Canneyt > Subject: Re: [fpc-pascal] GetTempFileName in Linux > To: FPC-Pascal users discussions > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > > On Wed, 6 Oct 2010, Jonas Maebe wrote: > >> >> On 06 Oct 2010, at 11:05, Michael Van Canneyt wrote: >> >>> On Wed, 6 Oct 2010, Jonas Maebe wrote: >>> >>>> On 06 Oct 2010, at 09:41, Michael Van Canneyt wrote: >>>> >>>>> This is always true on Unix, the only way to make sure is to have the >>>>> kernel >>>>> create the temporary name and file for you. Unix - to my knowledge - does >>>>> not have a way to create and lock a file in one atomic operation; There >>>>> are >>>>> always 2 operations involved, and so anything can happen between the 2 >>>>> calls. >>>> >>>> You can at least open a file with O_CREAT|O_EXCL|O_NOFOLLOW to make sure >>>> that it does not yet exist at the point that you create it (and that it's >>>> not a symlink either). >>> >>> This is correct, but doesn't lock the file, >> >> Locking is always advisory on Unix, so that doesn't matter anyway. >> >>> and so it doesn't prevent >>> someone from 'stealing' the file before the lock is applied. >> >> Nobody else can steal the file once you have created it, because they won't >> be the owner nor have the necessary permissions. That is the main security >> risk and it is solved by this approach. The fact that another process running >> under your login not using O_EXCL could overwrite it is not an extra security >> risk (if you have a rogue process running under your login, nothing that you >> do is safe because it can use ptrace to modify any process in any way it sees >> fit anyway). > > And that is why I think the whole point is hugely exaggerated :-) > > But it doesn't mean we shouldn't do our best to make it minimally safe. > > Michael. > > > -- > > Message: 2 > Date: Wed, 6 Oct 2010 12:57:02 +0200 > From: Jonas Maebe > Subject: Re: [fpc-pascal] GetTempFileName in Linux > To: FPC-Pascal users discussions > Message-ID: <6cd7d25a-fd10-4c7d-9011-da47560af...@elis.ugent.be> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > > On 06 Oct 2010, at 11:59, Michael Van Canneyt wrote: > >> On Wed, 6 Oct 2010, Jonas Maebe wrote: >> >>> Nobody else can steal the file once you have created it, because >>> they won't be the owner nor have the necessary permissions. That is >>> the main security risk and it is solved by this approach. The fact >>> that another process running under your login not using O_EXCL >>> could overwrite it is not an extra security risk (if you have a >>> rogue process running under your login, nothing that you do is safe >>> because it can use ptrace to modify any process in any way it sees >>> fit anyway). >> >> And that is why I think the whole point is hugely exaggerated :-) > > It's not, because currently a process from *another* user can > trivially intercept your temporary files. If you have a daemon running > as root, that is a major security concern. > > > Jonas > > >
Re: [fpc-pascal] lNet getting the local IP
On 06/10/10 14:27, Felipe Monteiro de Carvalho wrote:
Ok, thanks everyone, it seams that I managed to extract a function
from Silvio's code which doesn't use Synapse. I only tested in Windows
so far:
unit chesstcputils;
{$mode objfpc}{$H+}
interface
uses
{$IFDEF MSWINDOWS}
Winsock,
{$ENDIF}
Classes, SysUtils;
function ChessGetLocalIP(): string;
implementation
const
CFormatIPMask = '%d.%d.%d.%d';
function ChessGetLocalIP(): string;
var
I, VAttempt: Integer;
VStrTemp, VSitesToTry: TStringList;
{$IFDEF UNIX}
VProcess: TProcess;
{$ENDIF}
{$IFDEF MSWINDOWS}
var
VWSAData: TWSAData;
VHostEnt: PHostEnt;
VName: string;
{$ENDIF}
begin
Result := '';
{$IFDEF UNIX}
VStrTemp := TStringList.Create;
VProcess := TProcess.Create(nil);
try
VProcess.CommandLine :=
'sh -c "ifconfig eth0 | awk ''/inet end/ {print $3}''"';
Yuck. This doesn't work on my system (debian). If you really want the
least effort, you may have more luck with simply parsing `hostname -I`
somehow. The right way to do this is with an ioctl, I believe
(SIOCGIFCONF). Look here:
http://www.kernel.org/doc/man-pages/online/pages/man7/netdevice.7.html
I'm sure there's some code floating around, but it probably means that
you have to translate some headers :(.
Henry
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lNet getting the local IP
In our previous episode, Felipe Monteiro de Carvalho said:
> function ChessGetLocalIP(): string;
> VProcess.CommandLine :=
> 'sh -c "ifconfig eth0 | awk ''/inet end/ {print $3}''"';
Fails if eth0 is not the primary NIC. Doesn't work on non-linux (that use
other ethernet naming schemes)
A safe solution will probably boil down to walking the list of ethernet
adapters and routes to find the default route on *nix.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lNet getting the local IP
On Wed, Oct 6, 2010 at 7:55 AM, Sven Barth wrote: > You'll only find "127.0.0.1" for my computer there... I don't think that > this is a very good solution. Oh well. That makes sense b/c these are servers that I have obtaining the same IP over DHCP. On clients when DHCP is being used with dynamic IPs the host file may not be of much use or may require more parsing for the host name. But from a file based solution you just need to read in the /etc/hostname file. That is the name of the box. With the host name, ust search the /etc/hosts file for the IP matching that name. It's similar to the ifconfig command with parsing of eth0 which by the way if there are more than 1 nick, could be problematic. Is there an Gnome or KDE API we could use to officially get NIC related info like iphlpapi.dll API under Windows? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lNet getting the local IP
Ok, thanks everyone, it seams that I managed to extract a function
from Silvio's code which doesn't use Synapse. I only tested in Windows
so far:
unit chesstcputils;
{$mode objfpc}{$H+}
interface
uses
{$IFDEF MSWINDOWS}
Winsock,
{$ENDIF}
Classes, SysUtils;
function ChessGetLocalIP(): string;
implementation
const
CFormatIPMask = '%d.%d.%d.%d';
function ChessGetLocalIP(): string;
var
I, VAttempt: Integer;
VStrTemp, VSitesToTry: TStringList;
{$IFDEF UNIX}
VProcess: TProcess;
{$ENDIF}
{$IFDEF MSWINDOWS}
var
VWSAData: TWSAData;
VHostEnt: PHostEnt;
VName: string;
{$ENDIF}
begin
Result := '';
{$IFDEF UNIX}
VStrTemp := TStringList.Create;
VProcess := TProcess.Create(nil);
try
VProcess.CommandLine :=
'sh -c "ifconfig eth0 | awk ''/inet end/ {print $3}''"';
VProcess.Options := [poWaitOnExit, poUsePipes];
VProcess.Execute;
VStrTemp.LoadFromStream(VProcess.Output);
Result := Trim(VStrTemp.Text);
finally
VStrTemp.Free;
VProcess.Free;
end;
{$ENDIF}
{$IFDEF MSWINDOWS}
{$HINTS OFF}
WSAStartup(2, VWSAData);
{$HINTS ON}
SetLength(VName, 255);
GetHostName(PChar(VName), 255);
SetLength(VName, StrLen(PChar(VName)));
VHostEnt := GetHostByName(PChar(VName));
with VHostEnt^ do
Result := Format(CFormatIPMask, [Byte(h_addr^[0]), Byte(h_addr^[1]),
Byte(h_addr^[2]), Byte(h_addr^[3])]);
WSACleanup;
{$ENDIF}
end;
end.
--
Felipe Monteiro de Carvalho
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lNet getting the local IP
Am 06.10.2010 14:49, schrieb Andrew Brunner: I just read the first line in /etc/hosts file. The first entry is the IPv4. On Tue, Oct 5, 2010 at 3:04 PM, Felipe Monteiro de Carvalho wrote: hello, I am searching for a way to get the local IP. I already found examples with winsock, synapse and indy. Does anyone know how to do that with lNet? thanks, Huh?! O.o You'll only find "127.0.0.1" for my computer there... I don't think that this is a very good solution. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lNet getting the local IP
I just read the first line in /etc/hosts file. The first entry is the IPv4. On Tue, Oct 5, 2010 at 3:04 PM, Felipe Monteiro de Carvalho wrote: > hello, > > I am searching for a way to get the local IP. I already found examples > with winsock, synapse and indy. Does anyone know how to do that with > lNet? > > thanks, > -- > Felipe Monteiro de Carvalho > ___ > fpc-pascal maillist - fpc-pas...@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lNet getting the local IP
Hello, Actually it uses both synapse (under unix) and winsock (under Windows). What should one put in the parameter AHTTPSend: THTTPSend ? Where is this type declared? thanks, -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lNet getting the local IP
Local IP without winsock, synapse, indy or lnet: http://code.google.com/p/lazsolutions/source/browse/trunk/Core/LSHTTPSend.pas#127 2010/10/5 Felipe Monteiro de Carvalho > hello, > > I am searching for a way to get the local IP. I already found examples > with winsock, synapse and indy. Does anyone know how to do that with > lNet? > > thanks, > -- > Felipe Monteiro de Carvalho -- Silvio Clécio, *programmer* *ObjectPascal* ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] lNet getting the local IP
hello, I am searching for a way to get the local IP. I already found examples with winsock, synapse and indy. Does anyone know how to do that with lNet? thanks, -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] LNet
Am Freitag 11 Juni 2010, 18:50:56 schrieb Felipe Monteiro de Carvalho: > And from my tests Get is indeed returning the amount read. I still > don't know if half a packet could be received in the OnReceive event > or if it only returns an integer amount of packets. That makes > difference in the algorithm to separate the packets. IMHO your packets (not the TCP ones, I mean you own protocol) should always account for incomplete packets. Advantages: you can send more than the TCP window allows (which is usually around 60k bytes IIRC), and it doesn't matter if you get more than one packet with your Get - which also can happen. I usually keep a pretty simple binary protocol. A Packet consists of a Packet ID (byte or word or whatever amount of possible packets you need), and if that doesn't imply the size, that one too. So let's say packet IDs 1 to 5 are fixed size, I wouldn't need to supply their size too - would be a waste of bandwidth. Packet ID 6 however contains a text, so right after the packet ID I also send the expected packet size. On Receive, I write all that Get returns into a buffer (a queue to be more precise). Then I loop through that buffer for as long as it contains data and as the size of the buffer is equal or greater than the size of the next packet. Once I'm out of that loop, I get back to the wait-for-more state (i.e. Get, Get, Get :D) I do the same when sending: I put everything to send into a buffer, and then send it in as much chunks as necessary - Send will return how much it actually sent, that's the amount I take out of my send-buffer, and repeat, until the buffer hits zero or until the amount Send returns equals the amount in the buffer (whatever you prefer). If you want to see that implementation, let me know, it's opensource anyway. Best Regards, Andreas. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] LNet
I sent a direct main to Almindor and he answered my questions. Basically there is no direct way to detect the barrier between packages, you have to make your packet structure allow for that, but luckly mine was already prepared for this. And from my tests Get is indeed returning the amount read. I still don't know if half a packet could be received in the OnReceive event or if it only returns an integer amount of packets. That makes difference in the algorithm to separate the packets. -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] LNet
On Mon, 2010-06-07 at 14:15 +0200, Felipe Monteiro de Carvalho wrote: > Ok, thanks, now I seam to be able to get it working using > TLTCPComponent, but I am unsure about how to read data. > > Ok, I read that it will call OnReceive when there is data ready, but I > couldn't find anything about how much data is waiting to be read? > > I would like to get each single Packet which is sent to my program and > store them in a Queue, which will later be dealt with, but using only > the Get method I don't see how I can Find out how much data is > available. > > Without this I don't know how big a buffer I should send for this > function, but I guess I could just give a very big buffer, but then > there are no comments in the function indicating if it returns the > amount of bytes written. > > Also, how would I know where are the packets separated? I mean, two > packets could arrive very quickly and I would be reading both together > instead of first the first one and then the next one. did you have a look at the console http examples? fpget in this case? (examples/console/lhttp/fpget) Joost. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] LNet
Ok, thanks, now I seam to be able to get it working using TLTCPComponent, but I am unsure about how to read data. Ok, I read that it will call OnReceive when there is data ready, but I couldn't find anything about how much data is waiting to be read? I would like to get each single Packet which is sent to my program and store them in a Queue, which will later be dealt with, but using only the Get method I don't see how I can Find out how much data is available. Without this I don't know how big a buffer I should send for this function, but I guess I could just give a very big buffer, but then there are no comments in the function indicating if it returns the amount of bytes written. Also, how would I know where are the packets separated? I mean, two packets could arrive very quickly and I would be reading both together instead of first the first one and then the next one. thanks, -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] LNet
On Mon, Jun 7, 2010 at 10:41 AM, Graeme Geldenhuys wrote: > I don't use Lnet, so don't know if it already has two packages > (run-time and design-time) defined. It already has two packages, but the wiki page is geared towards the design-time one. -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] LNet
On Mon, 7 Jun 2010, Felipe Monteiro de Carvalho wrote: Hello, I am trying to use lNet and I have some questions. 1> Can I use TLTcp or do I need to use the "visual" version, TLTcpComponent? 2> Can I use only the base package or do I need to use the "visual" one? Basically I am not a big fan of design time packages, I prefer to add the units and create the components myself. 3> Does LNet require some kind of support for the widgetset? I am curious if TLTcp will work in Mac OS X or if it requires some support for the Carbon widgetset. And if it already works, then what is the mentioned support for widgetsets? As far as I know: In order to work, you need to tap into the message queue, because lnet is asynchrounously. The "widgetset integration" transparantly handles this for you. But if you call the message handling routines manually, then there is no dependency on the widgetset. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] LNet
On 07/06/2010, Felipe Monteiro de Carvalho wrote: > > 1> Can I use TLTcp or do I need to use the "visual" version, TLTcpComponent? > > 2> Can I use only the base package or do I need to use the "visual" one? > > Basically I am not a big fan of design time packages, I prefer to add > the units and create the components myself. Many times such packages come standard with an "artificial" dependency to LCL. The "component registration with the IDE component palette" is what pulls in the LCL dependency. Simply splitting such packages into two packages (Design-time and Run-time), then you simply need to use the Run-time package in your projects. I had to do the exact same thing for DCPCrypt, Epiktimer, OnGuard etc.. Note: I don't use Lnet, so don't know if it already has two packages (run-time and design-time) defined. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] LNet
You do not need to use Lazarus at all in order to develop with LNet. You do however need the runtime package in order to work with it if you want to use the TLTCPComponent, however if you do not want to use it, you simply need to tell the compiler where to find LNet, and use the normal classes. Ido On Mon, Jun 7, 2010 at 11:29, Felipe Monteiro de Carvalho < felipemonteiro.carva...@gmail.com> wrote: > Hello, > > I am trying to use lNet and I have some questions. > > 1> Can I use TLTcp or do I need to use the "visual" version, > TLTcpComponent? > > 2> Can I use only the base package or do I need to use the "visual" one? > > Basically I am not a big fan of design time packages, I prefer to add > the units and create the components myself. > > 3> Does LNet require some kind of support for the widgetset? I am > curious if TLTcp will work in Mac OS X or if it requires some support > for the Carbon widgetset. And if it already works, then what is the > mentioned support for widgetsets? > > thanks, > -- > Felipe Monteiro de Carvalho > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] LNet
Hello, I am trying to use lNet and I have some questions. 1> Can I use TLTcp or do I need to use the "visual" version, TLTcpComponent? 2> Can I use only the base package or do I need to use the "visual" one? Basically I am not a big fan of design time packages, I prefer to add the units and create the components myself. 3> Does LNet require some kind of support for the widgetset? I am curious if TLTcp will work in Mac OS X or if it requires some support for the Carbon widgetset. And if it already works, then what is the mentioned support for widgetsets? thanks, -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
