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,

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 <

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.

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.

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.

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,

did you have a look at the console http examples? fpget in this case? (examples/console/lhttp/fpget)

Joost.

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 wrote

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.