Getting Started

[Odevian]

I would like to use the lib in a Lazaraus/Freepascal project, but it is ultra hard to find an entry point or get a grasp of how complex this would turn out.
All the documentation I found was mainly a list of features. Or demos to examples like mail/smtp etc. that does not fit my use-case.

So my question is:
I would like to do a simple TCP or UDP state synchronization, say like in a game server. Clients connect, send some messages, the server should send appropriate messages to other clients. Maybe a chat function as an example starting point.

So, how you do it?
Which class to import into my project?
Where is the TTCP-/TUDP-Connection class?
I need a "Hello World with Synapse" kind of kickstart project, please!

TY!

[rvk01]

You probably already found the few examples at http://ararat.cz/synapse/doku.php/public:howto
There used to be a complete example directory in that came with the source but it seems to be gone since the transfer to github.
Maybe someone can restore it.

The old examples are still in some older clones of this github repo.
For example https://github.com/danielfppps/OpenKantu/tree/master/synapse/source/demo
There is a EchoServer example there (with lots of other examples).

For UDP you can also find several examples on the internet.
Like https://stackoverflow.com/questions/9786011/delphi-synapse-udp-client-server
And for multiple clients for example: https://www.lazarusforum.de/viewtopic.php?t=8315

Hope that's enough for you to get started 😉

[Odevian]

Thank you very much for your hints & pointers!

Having the examples from an older clone was very helpful. It is a pitty that they are not part of the official github currently.
The lazarusform had a nice code example as well.

I also found interesting bits by Remy Lebeau and you:
https://forum.lazarus.freepascal.org/index.php/topic,37868.15.html

[Odevian]

As I am experimenting with the synapse lib, I came across the following:

I am sending data from the main/GUI thread in Lazarus currently. I observed the "blocking" when calling sendString("myData") which is very noticable with a duration of about 1 second or so. Way too long for my purposes (I am trying to send positional data, like x/y coordinates).

I tried using the NonBlockMode := true and also setting the NonBlockSendTimeout := 10 as well as SetSendTimeout(10) and SetLinger(false, 0) in the hope to reduce that sending delay. The results were not satisfying tho.

I learned that I probably need to put the sending code in its own thread. I wonder tho, if I just extract the current code into a separate thread, will the sending delay be the same as I have observed? Where does that delay come from? What is the socket "waiting for" to send the data eventually?

Since I am using a UDP connection, I do not await a response or even a confirmation that there is someone listening at the remote end (in fact, it does not influence the delay if I have the server app running or not). My expectation is that the sending should be done in no time, even if I am calling it from the main/GUI thread. Is that a misconception?

Follow-up question I have in my head right now also is: If I create the sending thread, how do I "fill in" the data it has to send in a proper way? Do I need to have a queue for that?

[rvk01]

My expectation is that the sending should be done in no time, even if I am calling it from the main/GUI thread. Is that a misconception?

You are correct. Show your code which causes the 1 second delay (preferably a small complete console example).

Follow-up question I have in my head right now also is: If I create the sending thread, how do I "fill in" the data it has to send in a proper way? Do I need to have a queue for that?

Depends on your use case. Is it's just a one off you can just create a thread with sending string. If it's some kind of chat program where you fire off multiple string right after each-other, a queue solution might fit better.

[Odevian]

I see, probably a queue then. The idea to always create a thread is intruiging tho, never thought of something like that!
Thanks again for your input!

[Odevian]

I share my code stub here, maybe it is helpful for others:

Preparation: Use the Project Inspector to add the "blcksock.pas" file from the synapse lib to your project.
Afterwards a synapse connection can look like this:

unit SynapseConnection;

{$mode ObjFPC}{$H+}

interface

uses
  blcksock, // Synapse Lib
  sockets,  // TSocket
  SysUtils;

type
  TSynapseSocket = TUDPBlockSocket;

type

  { TSynapseConnection }

  TSynapseConnection = class
  private
    lib: TSynapseSocket;
  public
    constructor Create();
    constructor Create(useSocket: TSocket);
    destructor Destroy; override;
    procedure setup(address, port: String);
    procedure connect;
    function connected: Boolean;
    procedure disconnect;
    procedure send(Text: String);
  end;


implementation

{ TSynapseConnection }

constructor TSynapseConnection.Create();
begin
  lib := TSynapseSocket.Create();
(* experiments
  lib.NonBlockMode:= true;
  lib.NonblockSendTimeout:= 10;
  lib.SetSendTimeout(10);
  lib.EnableReuse(true);
  lib.SetLinger(false, 0);
*)
end;

constructor TSynapseConnection.Create(useSocket: TSocket);
begin
  Create();
  lib.socket := useSocket;
end;

destructor TSynapseConnection.Destroy;
begin
  inherited Destroy;
  FreeAndNil(lib);
end;

procedure TSynapseConnection.setup(address, port: String);
begin
(* better not set socksIP/Port unless you need to use a SOCKS Proxy
  lib.SocksIP := address;
  lib.SocksPort := port;
*)
  lib.SetRemoteSin(address, port);
end;

procedure TSynapseConnection.disconnect;
begin
  lib.CloseSocket;
end;

procedure TSynapseConnection.connect;
begin
  lib.Connect(lib.SocksIP, lib.SocksPort);
end;

function TSynapseConnection.connected: Boolean;
begin
  // is this the best way or even needed in UDP?
  Result := not lib.GetRemoteSinIP.IsEmpty;
end;

procedure TSynapseConnection.send(Text: String);
begin
  lib.SendString(text + CRLF);
end;


end.

[rvk01]

I share my code stub here, maybe it is helpful for others:

What does the calling procedure look like?
Are you using direct ip or hostname?

I'll try this tomorrow morning to see if I get a delay too. (Too late now)

[Odevian]

Thanks for your quick reply!

essentially I am creating the TSynapseConnection like this:

var
link: TSynapseConnection;

[...]

link := TSynapseConnection.Create();
link.setup('127.0.0.1', '5000');
link.connect;

Although there is no server app running or listening on that endpoint anyways.

The sending of data is done in a TTimer Event, which calls something like:
link.send(format('pos;%d;%d', [pos.x, pos.y])); // pos could also be random ints or just (0,0) doesn't matter

If I disable that timer, the freezing is gone. With timer enabled (interval 1 second), every time the timer event occurs, the app freezes instead of quickly sending the position and then go back to "normal" GUI thread operation again, as I would expect it to happen.

[rvk01]

The sending of data is done in a TTimer Event, which calls something like: link.send(format('pos;%d;%d', [pos.x, pos.y])); // pos could also be random ints or just (0,0) doesn't matter

I had to dive into this because this puzzled me. I had the delay here too.
But I found it.... you used lib.SocksIP := address; in your setup.
But when you assign a SocksIP then UDP uses a SOCKS proxy server to established a connection. This is done through a TCP connection (it connects TCP to SocksIP before sending UDP). It does this on every send. You can see the code in TUDPBlockSocket.UdpAssociation. There is the delay when trying to connect to the SOCKS proxy server on SocksIP.

So... you don't want to set a SOCKS proxy (do you?). If you just do a straight lib.connect(IP, Port) and not set SocksIP, then the sending of UDP is instant.

    {:Address of SOCKS server. If value is empty string, SOCKS support is
     disabled. Assingning any value to this property enable SOCKS mode.
     Warning: You cannot combine this mode with HTTP-tunneling mode!}
    property SocksIP: string read FSocksIP write FSocksIP;

[Odevian]

Thank you again! That is so valuable!
No, of course I didn't want to use a proxy. I just tried to figure out what property I had to set to have the socket use a certain IP and Port. The socksIP/socksPorts were the best match until I stumbled upon setRemoteSin (whatever that "Sin" stands for) and just left the rest as is... I also wasn't aware that the terms "Socks" and "Socket" are different concepts altogether.
(updated the code stub with comment on socksIP/Port)

Also, the sending is now instant! Works like a charm :D Now I need to get the server side going to receive that data...

[Odevian]

I am trying to get a simple UDP-send-receive setup going, but it won't work and I am out of ideas....
I have assembled a small commandline program to show the problem. Do you mind have a look?

There are just two sockets, one for sending one for listening and a receiverThread that wraps the listening socket.
The sender sends continuously some string message ("test"+i), but the receiver does not get any data at all. Only thing that happens is getting the timeout after recvString(). Also using just an Integer as message (using sendInteger()/recvInteger()) did not change anything.

There is one strange thing I observed:
In the current configuration the program's console output shows that the receiver thread is running in between the sends (although getting no data). But if you activate one/both of the lines in the DoRun() method currently commented out, the receiverThread does not give any lifesigns after "create" until sending of the last message is completed and the thread is terminated. As if something stops the thread from working after bind/connect on the sending (not the receiving!) socket...

I tried setting a family (SF_IP4) use CreateSocket or not, use bind, or connect, put the listening socket into listen() mode or not, terminating the sending String with CRLF or not etc etc.
No combination managed to get data through to the receiverThread or its socket.

(Note: The following code now contains the fixes suggested by geby in a later reply! Also freeing the sockets was added as gcarreno pointed out!)

program Project1;

{$mode objfpc}{$H+}

uses
  {$IFDEF UNIX}
  cthreads,
  {$ENDIF}
  Classes, SysUtils, CustApp,
  { you can add units after this }
  blcksock;

type

  TSynSock = TUDPBlockSocket;

  { TReceiverThread }

  TReceiverThread = class(TThread)
  private
    socket: TSynSock;
  protected
    procedure Execute; override;
  public
    constructor Create(useSocket: TSynSock); overload;
  end;

  { TMyApplication }

  TMyApplication = class(TCustomApplication)
  protected
    listening: TSynSock;
    sending: TSynSock;
    receiver: TReceiverThread;
    procedure DoRun; override;
  public
    constructor Create(TheOwner: TComponent); override;
    destructor Destroy; override;
  end;

  { TReceiverThread }

  constructor TReceiverThread.Create(useSocket: TSynSock);
  begin
    Create(false);
    Self.socket := useSocket;
    writeln('ReceiverThread created');
  end;

  procedure TReceiverThread.Execute;
  var
    Data: String;
  begin
    while not Terminated do
    begin
      writeln('   ReceiverThread execute');
      Data := socket.RecvPacket(2000);  // use recvPacket in UDP, not recvString
      writeln('   ReceiverThread got: ' + Data);
      writeln('   ReceiverThread status: ' + socket.LastErrorDesc);
    end;
    writeln('     ReceiverThread terminated');
  end;

  { TMyApplication }

  procedure TMyApplication.DoRun;
  var
    i: Integer;
    msg: String;
  begin
    try
    writeln('Start');

    listening := TSynSock.Create;
    listening.Bind('127.0.0.1', '20000');
    // listening.listen; only needed in TCP
    receiver := TReceiverThread.Create(listening);
    receiver.Start;

    sending := TSynSock.Create;
    //sending.bind('127.0.0.1', '19000'); only for TCP
    sending.connect('127.0.0.1', '20000');
    //sending.SetRemoteSin('127.0.0.1', '20000'); // not needed in UDP

    for i := 0 to 30 do
    begin
      msg := 'test' + IntToStr(i);
      writeln('Sending: ' + msg);
      sending.SendString(msg);
      sleep(random(1000));
    end;
    sending.closeSocket;

    receiver.Terminate;
    receiver.WaitFor;
    listening.closeSocket;

    writeln('Finished. Press Enter to quit.');
    readln();

    Terminate;
  finally
    sending.free;
    listening.free;
    receiver.free; 
  end;
  end;

  constructor TMyApplication.Create(TheOwner: TComponent);
  begin
    inherited Create(TheOwner);
  end;

  destructor TMyApplication.Destroy;
  begin
    inherited Destroy;
  end;

var
  Application: TMyApplication;
begin
  Application := TMyApplication.Create(nil);
  Application.Title := 'My Application';
  Application.Run;
  Application.Free;
end.

[gcarreno]

Hey Odevian(@Odevian),

I had a very quick look at your code and something's a miss...

For context:
The way the server side of a network connections works is like this:

1. You bind the socket to an IP:Port pair.
2. You call listen and this blocks until a connection is made.
3. Usually, upon a connection, listen will unblock.
4. You then call accept on the listening socket, to return a socket that represents the connection made.
5. You then use that returned socket to send/receive data from the client.

From my experience there are 2 ways to tackle this:

1. If you're doing a GUI app, you'll wrap the listening code with the bind/listen/accept with an outer thread and then pass the connected/accepted socket to another thread to deal with the back and forth. This way, the GUIs main thread does not get stuck on the listen.
2. If you're doing a CLI app, you don't really mind if it blocks on the listen, so you just have the thread to deal with the back and forth.

From the very quick read of your code, I couldn't find the call to accept after the call to listen.

BTW, once you're done with the socket, please make sure you close that socket(both the listening and the accepted ones). Strange things can happen with dangling sockets, just like dangling pointers 😉
Remember that sockets are a finite resource and if you don't close them, the kernel will probably run out of descriptors after a few thousand connections.

Hope this helps with your case.

Cheers,
Gus

[Odevian]

That is strange... I had a version with an accept but the socket gave me an error "This operation is not allowed on this socket", which made me think that the accept is maybe only needed on a TCP connection. I am dealing with a UDP connection.

The note on listen() and its blocking behaviour might explain my observation with the "stalled" thread maybe!

I'll try a new version with your input. Thanks a lot for your time and reply! Good point with the resource freeing!

[geby]

Basic UDP usage idea is:

client:
udp.connect - to set server IP and port
udp.sendstring - to send packet to the server
udp.recvpacket - to receive server reply

server:
udp.bind - to set listening port
udp.recvpacket - to read clients request
//process request and generate reply
udp.sendstring - to send reply back

listen or accept is for connection oriented sockets like TCP. UDP is datagram based. Any manipulations with remotesin not needed. Each call of RecvPacket sets Remotesin internally, and it is used by subsequent send operation.

Do not use recvstring on UDP. It is designed to stream based sockets. Use RecvPacket instead - it receive one full datagram.

[gcarreno]

Hey @geby,

Thanks for the distinction between TCP way and UDP way.
I've never done anything with UDP, so I wasn't sure it was the same. From your explanation, it is not, but it makes sense.

Cheers,
Gus

[Odevian]

Yes! That worked! Awesome! :D Thank you for your help!
(Updated the commandline program code above)