Questions about socket programming

Questions about socket programming

[Hubert]

Hello,

I want to write a small telnet server as an exercise and also because I 
need this functionality elsewhere. I seem to remember that I read in 
this newsgroup somewhere some negative opinions about Gnatsockets, but I 
can't remember where and what it was about.
So I wonder, should I use Gnatsocket or are there any problems? Should I 
rather interface with C and use the C socket implementation directly? I 
must admit that I tried this today and didn't get very far, because I 
got linker errors like these:

Berkley_Socket_Interface_C.c:47: undefined reference to 
`_imp__getaddrinfo@16'

Berkley_Socket_Interface_C.c:48: undefined reference to `gai_strerrorA'

Berkley_Socket_Interface_C.c:49: undefined reference to `_imp__WSACleanup@0'

collect2.exe: error: ld returned 1 exit status


and I am out of ideas there. I tried to add to the C linker the 
following switches:

-lwsock32 -lws2_32

but without luck. I found contradictory information what the correct 
library name is for mingw, so I tried both but apparantly both are 
wrong, or the respective libraries are not delivered with Adacore Libre.
I should had that I don't have Mingw installed, just what comes with 
Adacore.

Thanks for any help


---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com

Re: Questions about socket programming

[David Botton]

> So I wonder, should I use Gnatsocket or are there any problems?

For a telnet like service there is little to be concerned with in using the Gnat Socket implementation and there would be no advantage (perhaps disadvantages) to writing your own binding to the same libraries.

If I understand correctly, and perhaps I don't, the complaints have more to do with performance issues on scales not relative to what you are trying to accomplish.

David Botton

Re: Questions about socket programming

[Hubert]

On 12/24/2014 6:22 AM, David Botton wrote:
>> So I wonder, should I use Gnatsocket or are there any problems?
>
> For a telnet like service there is little to be concerned with in using the Gnat Socket implementation and there would be no advantage (perhaps disadvantages) to writing your own binding to the same libraries.
>
> If I understand correctly, and perhaps I don't, the complaints have more to do with performance issues on scales not relative to what you are trying to accomplish.
>
> David Botton
>

Ok, thanks, yes I am expecting 1 or a few connections to the server at 
best, so I won't bother with the C layer then.


---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com

Re: Questions about socket programming

[Randy Brukardt]

"David Botton" <david@botton.com> wrote in message 
news:7671ca8e-eb53-412f-8b88-d09cb04c66cc@googlegroups.com...
>> So I wonder, should I use Gnatsocket or are there any problems?
>
> For a telnet like service there is little to be concerned with in using 
> the Gnat Socket implementation and there would be no advantage (perhaps 
> disadvantages) to writing your own binding to the same libraries.

Unless you want it to work with other Ada compilers (to avoid GNAT lock-in).

> If I understand correctly, and perhaps I don't, the complaints have more 
> to do with performance issues on scales not relative to what you are 
> trying to accomplish.

*My* complaint is simply that you end up with GNAT lock-in whenever you 
depend on GNAT-specific packages. Ada is powerful enough that such lock-in 
shouldn't be necessary. So it's better to use a package that is more 
portable, like Claw.Sockets (if you're already locked into Windows) or 
Adasockets or (coming soon) NC_Sockets.

                                            Randy.

Re: Questions about socket programming

[Dmitry A. Kazakov]

On Fri, 26 Dec 2014 19:21:48 -0600, Randy Brukardt wrote:

> Ada is powerful enough that such lock-in 
> shouldn't be necessary.

It isn't. There is no way to implement sockets in Ada without doing system
calls.

Obviously sockets should be included into the standard library. Even
considering embedded targets, socket I/O is probably more relevant there
than text I/O, which is a part of the library.

GNAT sockets could be a good reference point. The only important (for
embedded applications) part missing is raw sockets.

> So it's better to use a package that is more 
> portable, like Claw.Sockets (if you're already locked into Windows) or 
> Adasockets or (coming soon) NC_Sockets.

Actually GNAT sockets are more portable than AdaSockets, as they work on a
wider set of targets (e.g. VxWorks). You mean compiler independence.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Questions about socket programming

[David Botton]

> *My* complaint is simply that you end up with GNAT lock-in whenever you 
> depend on GNAT-specific packages.

Copy, paste, rename. If AdaCore could redo history based on current policies I'm sure that GNAT.Sockets would have been part of GNATCOLL anyways.

David Botton

Re: Questions about socket programming

[Hubert]

It would be good if there were a compiler and OS independent basic 
library I guess, but that doesn't seem to exist. So for me as a beginner 
I guess I take whatever help I can and since I dont see me switching 
compilers in the near future I stick with Gnat. Actually I hope I can 
use the Gnat server class from Dmitry's collection library, I will know 
in a day or two.
Ada is hard enough to master when you come from VisualStudio because of 
all the help the IDE provides. GPS is not as powerful, but seems to be 
usable. I know the Janus compiler is out there, but I must say that GPS 
is one of the main arguments for me to use Gnat because it shields me 
from many of the complicated issues that I don't want to deal with as a 
newbie.


---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com

Re: Questions about socket programming

[Dmitry A. Kazakov]

On Wed, 24 Dec 2014 05:43:21 -0800, Hubert wrote:

> I want to write a small telnet server as an exercise and also because I 
> need this functionality elsewhere. I seem to remember that I read in 
> this newsgroup somewhere some negative opinions about Gnatsockets, but I 
> can't remember where and what it was about.

I am using GNAT.Sockets extensively, there is no problems so far.

> So I wonder, should I use Gnatsocket or are there any problems? Should I 
> rather interface with C and use the C socket implementation directly? I 
> must admit that I tried this today and didn't get very far, because I 
> got linker errors like these:
> 
> Berkley_Socket_Interface_C.c:47: undefined reference to 
> `_imp__getaddrinfo@16'
> Berkley_Socket_Interface_C.c:48: undefined reference to `gai_strerrorA'
> Berkley_Socket_Interface_C.c:49: undefined reference to `_imp__WSACleanup@0'
> 
> collect2.exe: error: ld returned 1 exit status
> 
> and I am out of ideas there. I tried to add to the C linker the 
> following switches:
> 
> -lwsock32 -lws2_32

Windows sockets are not Berkeley sockets and conversely. Which is one
reason to use GNAT.Sockets instead.

> but without luck. I found contradictory information what the correct 
> library name is for mingw, so I tried both but apparantly both are 
> wrong, or the respective libraries are not delivered with Adacore Libre.

There are WinSock versions 1 and 2. See

   http://en.wikipedia.org/wiki/Winsock

> I should had that I don't have Mingw installed, just what comes with 
> Adacore.

You can implement Telnet server on top of this:

http://www.dmitry-kazakov.de/ada/components.htm#multiple_GNAT.Sockets.Servers

or this:

http://www.dmitry-kazakov.de/ada/components.htm#GNAT.Sockets.Connection_State_Machine

The first handles socket communication for you, the second parses incoming
packets as well.

Merry Christmas,

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Questions about socket programming

[Hubert]

Thanks, I downloaded the package now and check it out. Can you tell me 
if the server package handles long data as well? I understand that the 
basic socket send() function sends only as much as fits into the 
outgoing buffer and has to be called multiple times for large data 
blocks, whereupon the recieve() function must be called multiple times 
as well and the original datablock then reassembled by the application. 
Does your server handle that scenario and return the original large 
datablock or is that left for the application as well?



---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com

Re: Questions about socket programming

[Hubert]

Ok, I think I found the answer already, it appears that the Send() 
function works similar to the low level send() and sends out only as 
much data as fits into the buffer.

---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com

Re: Questions about socket programming

[David Thompson]

On Wed, 24 Dec 2014 20:02:42 -0800, Hubert <herrdoktor@fumanchu.com>
wrote:

> Thanks, I downloaded the package now and check it out. Can you tell me 
> if the server package handles long data as well? I understand that the 
> basic socket send() function sends only as much as fits into the 
> outgoing buffer and has to be called multiple times for large data 
> blocks, whereupon the recieve() function must be called multiple times 
> as well and the original datablock then reassembled by the application. 
> Does your server handle that scenario and return the original large 
> datablock or is that left for the application as well?
> 
TCP is a stream protocol. Do not assume that each send on one side
corresponds to one recv on the other side; that may work in a test lab
with two high-end machines connected by a single uncongested and
error-free high-speed LAN. In the real internet data may be split up,
combined, or both, usually in ways that depend on fluctuating and
unreproducable conditions in places you can't measure.

Always design TCP apps so that they either treat data as a stream
(which TELNET does) or any needed "records" are self-delimiting --
common methods are terminating chars like CRLF in SMTP/NNTP and FTP
commands and HTTP headers, prefix length fields like SSL/TLS, SSH, and
modern HTTP data, or  closing the TCP connection where there is only
one record like old HTTP or basic FTP.

If you want record boundaries preserved, use newer (and rarer) SCTP
instead. Or use UDP if you need records but can live with fairly small
limits (possibly as small as about 512 bytes), and possible loss,
duplication and reordering.

Re: Questions about socket programming

[Hubert]

Thanks, thats a valuable hint. I am not very experienced in socket 
programming, for my main work I use a network library that takes care of 
all this on a higher level, so low level sockets provide some surprises 
for me


---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com

Re: Questions about socket programming

[Dmitry A. Kazakov]

On Mon, 12 Jan 2015 20:31:46 -0800, Hubert wrote:

> Thanks, thats a valuable hint. I am not very experienced in socket 
> programming, for my main work I use a network library that takes care of 
> all this on a higher level, so low level sockets provide some surprises 
> for me

No library can take care unless it understands protocol framing. The point
is that TCP/IP sockets do not have visible framing. Except for one
important case when the NO_DELAY socket option is set. Normally the TCP/IP
stack splits outgoing stream into frames as it finds appropriate.
Furthermore the content source is not required to call a send for each
frame. Single send may cause several frames sent and conversely several
sends can coalesced into one frame.

So whatever logical framing may be present, it always comes from the
higher-level protocol running over TCP/IP transport. E.g. in the case of
Telnet it would be lines, CR-LF terminated, if I correctly remember.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Questions about socket programming

[Hubert]

Yes, I should have mentioned that. I use Raknet which has it's own data 
wrapper and assembles data on the receiving end correctly so you always 
get one read fro one send. But of course I can't use that for mey telnet 
server project, so here I'm dealing with new stuff. Good to know that 
thre are these problems on the TCP/IP level, I will see to it that I 
treat everything that I read out as a stream of bytes


---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com

Re: Questions about socket programming

[Dmitry A. Kazakov]

On Tue, 13 Jan 2015 12:31:29 -0800, Hubert wrote:

> Yes, I should have mentioned that. I use Raknet which has it's own data 
> wrapper and assembles data on the receiving end correctly so you always 
> get one read fro one send. But of course I can't use that for mey telnet 
> server project, so here I'm dealing with new stuff. Good to know that 
> thre are these problems on the TCP/IP level, I will see to it that I 
> treat everything that I read out as a stream of bytes

The state machine I mentioned before handles this. You put a terminated
string element into the derived type with 'CR' as the terminator. Next you
put expected element, that expects 'LF'. That will cause Process_Packet
called each time a complete line was received.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Questions about socket programming

[Kevin K]

I've used Gnat.Sockets when the project I was working on started to support Windows in addition to Linux.

It reduced the number of unique files that were required between the 2 systems.

The main issues we encountered were issues with the Gnat Sockets select call.  GNAT uses a hidden socket in the background to enable termination of the select, and there was some interaction with our code that caused exceptions sporadically.  Never able to reproduce it in a small test case. I ended up writing a companion package that would use the OS calls for the select, with no issues. It has been several years, so it may be fixed now.

The other, as mentioned, were raw sockets.  Due to project requirements, we needed to be able to specify several IP header fields exactly, and the TOS capability isn't supported on modern Windows.