Hello, gentlemen!
Are there any modules for GPC which allow me to implement IPC with sockets?
I know that I can write such a library in C and then create it as pascal library, but why to invent the wheel?
Thank you in advance,
Nick
Nick Ioffe wrote:
Hello, gentlemen!
Are there any modules for GPC which allow me to implement IPC with sockets?
I know that I can write such a library in C and then create it as pascal library, but why to invent the wheel?
I wrote a little `Socket' unit, which only supports some features yet (but can be extended, of course). It's included in "Mail tools" on http://fjf.gnu.de. Some demos (ServerDemo, ClientServerDemo) are also on the page.
Frank
Are there any modules for GPC which allow me to implement IPC with sockets?
I know that I can write such a library in C and then create it as pascal library, but why to invent the wheel?
Personally, I just external the socket stuff directly and write to that, eg:
type sockaddr = packed record sin_len: UInt8; sin_family: UInt8; sa_data: packed array[0..13] of UInt8; end; sockaddr_in = packed record sin_len: UInt8; sin_family: UInt8; sin_port: UInt16; sin_addr: ipAddr; sin_zero: packed array[0..7] of UInt8; end; sockaddr_in_ptr = ^sockaddr_in;
function socket( domain: int; typ: int; protocol: int ): int; external name 'socket'; function bind( socket: int; name: sockaddr_in_ptr; namelen: int ): int; external name 'bind'; function listen( socket: int; backlog: int ): int; external name 'listen'; function accept( socket: int; name: sockaddr_in_ptr; var namelen: int ): int; external name 'accept'; function connect( socket: int; name: sockaddr_in_ptr; namelen: int ): int; external name 'connect';
and so forth.
It's a triffle tedious to convert the C stuff over, but since I do it ad hoc as needed, it's not to bad at any one time. It's a bit error prone and obviously not going to handle changing the interfaces or porting to another unix system, but my code is all heaviy Mac specific anyway so no big deal there.
Enjoy, Peter.
Peter N Lewis wrote:
It's a triffle tedious to convert the C stuff over, but since I do it ad hoc as needed, it's not to bad at any one time. It's a bit error prone and obviously not going to handle changing the interfaces or porting to another unix system, but my code is all heaviy Mac specific anyway so no big deal there.
Of course, you can do in your own code as you please. However, I'd prefer if on this list portable techniques were advocated where available.
Here, a little C wrapper can easily use the system header definitions, and since it's only needed for setting up/closing a connection etc., while the actual socket I/O can go through regular files, the (anyway small) performance overhead should be negligible.
Frank
At 9:57 PM +0200 12/8/03, Frank Heckenbach wrote:
Peter N Lewis wrote:
It's a triffle tedious to convert the C stuff over, but since I do it ad hoc as needed, it's not to bad at any one time. It's a bit error prone and obviously not going to handle changing the interfaces or porting to another unix system, but my code is all heaviy Mac specific anyway so no big deal there.
Of course, you can do in your own code as you please. However, I'd prefer if on this list portable techniques were advocated where available.
The code is portable if the interfaces are generated automatically. That bit has not been implemented unfortunately, and since requires parsing C headers, is quite challenging, so the interfaces are generated manually. Other than that, coding to the sockets layer is certainly portable.
Here, a little C wrapper can easily use the system header definitions, and since it's only needed for setting up/closing a connection etc., while the actual socket I/O can go through regular files, the (anyway small) performance overhead should be negligible.
I'm not sure what you mean by "regular files". Personally, I do network transfer code that has to transfer at the speed of the harddisk, so I prefer to avoid any wrapping in the actual transfer, thought as you mention, wrapping the connect etc is not really an issue. However, error handling does become an issue for any wrapped code, writing robust code with other peoples wrappers is often very challenging as you have to know exactly how things are implemented in order to get it exactly right, especially with the sockets API.
Ideally we'd have direct access to the POSIX API on any given system, but until we can parse the C headers on each platform to make Pascal interfaces, that's probably not going to happen. The next best thing might be to make a Posix.pas file for each platform that is generated somewhat automatically and somewhat manually.
Enjoy, Peter.
Peter N Lewis wrote:
The code is portable if the interfaces are generated automatically. That bit has not been implemented unfortunately, and since requires parsing C headers, is quite challenging, so the interfaces are generated manually. Other than that, coding to the sockets layer is certainly portable.
I was referring to the manual header translation. Lacking a fully automatic tool (which is indeed very challenging and hopefully possible at all), C wrappers are the second best solution (just as safe, with only a little (in this case) overhead).
Here, a little C wrapper can easily use the system header definitions, and since it's only needed for setting up/closing a connection etc., while the actual socket I/O can go through regular files, the (anyway small) performance overhead should be negligible.
I'm not sure what you mean by "regular files".
Well, Pascal file types.
Personally, I do network transfer code that has to transfer at the speed of the harddisk, so I prefer to avoid any wrapping in the actual transfer,
Of course, Pascal files are "wrapped" by the Pascal runtime. If that's too much for you and, I assume, you're using direct read(2)/write(2) for the harddisk files involved, then you might have to do the same for the sockets, indeed.
Ideally we'd have direct access to the POSIX API on any given system, but until we can parse the C headers on each platform to make Pascal interfaces, that's probably not going to happen. The next best thing might be to make a Posix.pas file for each platform that is generated somewhat automatically and somewhat manually.
As I said, for connect etc., wrappers should be no problem. And read/write is done just the same as for other files, including the error handling. If that's lacking in some regard, it might be better to improve it in the RTS (for all files).
Frank
-
"Nick Ioffe -
Frank Heckenbach -
Peter N Lewis