Comments for lNet - Lightweight networking library

Comment on Handles, Eventers and Events by almindor

almindor — Sun, 18 Nov 2012 18:26:42 +0000

Replied in the thread

Comment on Handles, Eventers and Events by Robin Hoo

Robin Hoo — Sun, 18 Nov 2012 12:13:36 +0000

Pls check out the bug fix of winsocket.pp of post http://www.lazarus.freepascal.org/index.php/topic,18913.0.html

Comment on Sockets, Protocols and Sending by Ryan Davis

Ryan Davis — Fri, 15 Jun 2012 23:25:29 +0000

I’ve tried to replicate this behavior. I was experiencing it consistently one day all day, however, I haven’t been able to get it to happen again. It’s consistency may have been an artifact of my virtual machine I use to run Windows, which I recently changed (VMWare to Parallels). If I see it again I’ll let you know. Meanwhile, I have another question, that I’ll ask below.

Comment on Sockets, Protocols and Sending by Andyk

Andyk — Mon, 11 Jun 2012 12:46:21 +0000

OK!

I’ve deleted the eventer I created manually and let the connect routine create its own which seems to work. Although i had to add a call callAction to make the connect event fire.

Originally, I couldn’t get anything to work without the eventer, it just came up with error’s, Seems to work now though.

I’m using the telnet protocol although in Delphi I created a wrapper around the Tclientsocket. I really need a blocking communication channel that acts like an ASCII RS232 connection for communicating with scientific instrumentation.

When I tried to set the lnet ssblocking state, it just gave an error though. Is there an easier way to do this ?

Comment on Sockets, Protocols and Sending by almindor

almindor — Mon, 11 Jun 2012 11:09:59 +0000

TLEventer is just the abstract ancestor to specific eventers like TLSelectEventer or TLEpollEventer. Your eventer is either created automatically by lNet (on first call to Listen/Connect) in which case you can use the component directly (e.g.: TLTcp.CallAction) or you create them yourself. Unless you need your own specific eventer type, you should always create the best eventer for given platform via the levents.BestEventerClass().

Comment on Sockets, Protocols and Sending by Andyk

Andyk — Mon, 11 Jun 2012 10:57:56 +0000

Can’t get callAction to work on version 0.6.5, the eventer code seems to just return true. Is this a bug ?

function TLEventer.CallAction: Boolean;
begin
Result := True;
// override in ancestor
end;

Comment on Sockets, Protocols and Sending by almindor

almindor — Mon, 04 Jun 2012 16:44:01 +0000

So the server has this error? Sending buffer full occurs when you try to send too much data at once. You should only get a send = 0 tho and OnCanSend should fire when the OS is ready to send more. Are you using this event, is the handler assigned? It probably works on Mac OS X because it has bigger default OS send buffers.

Comment on Sockets, Protocols and Sending by Ryan Davis

Ryan Davis — Mon, 04 Jun 2012 15:18:57 +0000

I have a question. I’m using lnet currently cross-platform on Mac and Windows using the non-visual methods. I currently have a server hosting and then the same application that has the server connects to that server with a client as well as copies of the application from elsewhere connect via their client.

In practice this works rather well for most things. Indeed, when I want to test things on Mac I run two copies of the program and connect them using 127.0.0.1. It works fine on Mac.

However, I tried doing this same operation on Windows, where I test the application by connecting two copies to 127.0.0.1 and every time I do it the hosting application freezes with the error “Send buffer full, try again later.” I’ve heard of other people getting this error before too, though inconsistently, when connecting over the internet normally.

What causes this error and how can it be preempted or prevented? How can I run two copies of the same app for testing on Windows like I do on Mac and also prevent this error from ever troubling my users in general?

Comment on Sockets, Protocols and Sending by almindor

almindor — Sun, 03 Jun 2012 08:31:42 +0000

Good question. I remember these problems myself but IIRC I also did some call to “wake up” the port assignment so to speak. If there’s no other way, we could add a cross-platform functionality and integrate it to lNet.

Comment on Sockets, Protocols and Sending by zandoye

zandoye — Sun, 03 Jun 2012 07:05:03 +0000

Hi, I have several game servers start and quit on demand, so these server processes doesn’t listen to fixed number ports. They(tLTcp) start, listen to (*,0), then register their port number that allocated by OS on a NameServer.
I’v tried
> writeln(‘host: ‘, sock.host, ‘ port: ‘, sock.port);
> writeln(‘host: ‘, sock.RootSock.localAddress, ‘ port: ‘, sock.RootSock.localPort);
> writeln(‘host: ‘, sock.RootSock.peerAddress, ‘ port: ‘, sock.RootSock.peerPort);
but the three statements all print out zero.

Now, I have to invoke
> fpGetSockName(sock.RootSock.handle, @sockAddr, @sockAddr_size);
> writeln(‘host: ‘, hostAddrToStr(in_addr(nToHl(sockAddr.sin_addr.s_addr))), ‘ port: ‘, nToHs(sockAddr.sin_port));
to get the real port number.

I’m using lnet svn reversion 2591.
Is there an easy and portabal way to get the real port that is listening to?