Recent

Author Topic: What do you reach for when you need non blocking TCP sockets?  (Read 1031 times)

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1130
Re: What do you reach for when you need non blocking TCP sockets?
« Reply #15 on: August 10, 2022, 02:16:52 pm »
Hi Gus,

I just wanted to say that both the timer and socket have an interrupt build in that wakes your thread when something happens. And if you use Synapse, it creates the thread that handles the receiving automatically when the connection is accepted, as long as you use their examples.

But I agree that it was a bit patronizing of me  :P

Greetings, Frank

MarkMLl

  • Hero Member
  • *****
  • Posts: 5540
Re: What do you reach for when you need non blocking TCP sockets?
« Reply #16 on: August 10, 2022, 02:52:45 pm »
Yeah, you're absolutely right and I made a mess of it again. It's not ICMP related. I'm sorry for the confusion that I spread!!

No apology needed. But if it were ICMP you'd (a) need to use a different API and (b) find that on unix ping and tracert are either setuid root or have a special POSIX attribute to allow them to be run by an unprivileged user.

Code: Text  [Select][+][-]
  1. # getcap `which ping`
  2. /usr/bin/ping = cap_net_raw+ep
  3.  

Quote
You're then gonna argue that the triple handshake of a TCP connection and the methods that have been put in it's planning are enough to make the connection be kept alive, and you're right.

I most definitely am not, since (a) the detail of that is outside the scope of Berkeley Sockets and (b) following nmap's lead and using a handshake as a probe can trigger intrusion detectors (one of our customers once raised this with me, and was impressed when I explained that we had various things in place to ensure that we knew promptly if something happened which would prevent their receiving scheduled reports).

Now jumping back a couple of paras:

Quote
My example is based on a custom protocol that relies on New Line(Indy's WriteLn on a socket) terminated strings that I did not invent and I'm kinda stuck with.

Bear in mind that TCP is a stream protocol, and just because a message is sent with an EOL there's no guarantee that it will be received as a single EOL-terminated message. Particularly for short messages it /usually/ will, but you /will/ eventually hit a situation where the single message sent

Code: [Select]
Test message\r\n

is actually read back as two messages

Code: [Select]
Test m
essage\r\n

The result of that is that what you really need to do is have the thread do a blocking read on the open connection, accumulate the input, and only when it has seen an intact message enqueue it and e.g. use Synchronise() to tell the main thread that there's something to be looked at.

Yes, I know: small messages should work. But consider the situation where the connection is broken at some point, an intermediate router accumulates multiple messages, and when the connection comes back up it repacks them with borders different from the original. TCP acks use a sliding window, and instead of OKing specific messages they OK byte ranges: the protocol /expects/ the stream to be repackaged depending on the characteristics of intervening hops.

UDP (and for that matter ICMP) does respect boundaries... but determining the end-to-end MTU (Maximum Transmission Unit) can be a problem and there is no guarantee that it will stay the same during the lifetime of a connection. But UDP doesn't guarantee delivery, and doesn't guarantee sequential delivery. There's the outline of using UDP to check that a DNS server is live at https://forum.lazarus.freepascal.org/index.php/topic,59807.msg447776.html#msg447776 although this doesn't use a background thread.

SCTP is, like the above, a transport layer protocol. However it both preserves message boundaries and is reliable, unfortunately it's also fairly "heavyweight" and you probably won't find NATting ADSL (etc.) routers that support it (I've run it over a tunnel through a Draytek router, but couldn't over the router itself).

RDP is an obsolete transport layer protocol which preserves message boundaries and has various options which allow it to deliver out-of-sequence messages to the client: the example in the RFC is a debugger which might want to capture a target system's memory but doesn't have to get everything sequentially.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

sketch

  • New Member
  • *
  • Posts: 11
Re: What do you reach for when you need non blocking TCP sockets?
« Reply #17 on: August 10, 2022, 03:48:56 pm »
Yeah, you're absolutely right and I made a mess of it again. It's not ICMP related. I'm sorry for the confusion that I spread!!

No apology needed. But if it were ICMP you'd (a) need to use a different API and (b) find that on unix ping and tracert are either setuid root or have a special POSIX attribute to allow them to be run by an unprivileged user.

Code: Text  [Select][+][-]
  1. # getcap `which ping`
  2. /usr/bin/ping = cap_net_raw+ep
  3.  

Regarding Capabilities (cap_net_raw), that is a Linux thing and not Unix.  AIX, Solaris, and HP-UX do not implement it, or to the best of my knowledge have not.  But I last used Solaris 10 and Aix 6.x, so maybe they have added Capabilities (Posix 1003.)  Sorry to be nitpicking  ::)

If IBM and Oracle have added that in AIX and Solaris, then I stand corrected -- and embarrassed.  :-[

MarkMLl

  • Hero Member
  • *****
  • Posts: 5540
Re: What do you reach for when you need non blocking TCP sockets?
« Reply #18 on: August 10, 2022, 04:00:04 pm »
I said it's /either/ setuid root /or/ it uses POSIX capabilities. I didn't speculate on how compliant IBM et al. were with any particular facet of the POSIX specs >:-)

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

 

TinyPortal © 2005-2018