Server/client sync - when can I write to a socket?

[techcode]

Dear monks,

EDIT: I read that in Perl working with sockets is just like working with file handles - and in some weird way assumed that both sides can't write to it at the exactly same time. That of course makes sense IMO for (one) file - but not quite for the sockets - so can both sides write at the same time?

If they can indeed both write at the same time - and read what they are receiving (if there is anything - will use can_read() to check) when they want (when they are not sending) - then I'm all settled and clear. Each operation is accompanied by some unique (circulating 00 to 99) number - and it's response to the other side also includes that number.

I need some guidance regarding network programming - and specifically it would be excellent if someone has EMI/UCP protocol experience.

My first hope was to use Net::UCP or Net::EMI - just like I did with excellent Net::SMPP - but I just can't get either of these two to work. Finding out that in reality only a small subset of operations (commands) defined in EMI/UCP protocol is still in use today (for SMS's anyway) (and I need even smaller - getting to ~ 5 commands) I would like to give a shot at writing my own implementation.

I understand almost everything but one thing - how is synchronization done? I see there are commands that server initiates (sms delivery report as one of them) - and I wonder how can I know when I can write to a socket?

EMI/UCP specification leaves much to be desired (docs of Net::EMI and Net::UCP even more so) in terms of explaining the "whole forest" and not just specific "trees". So if anyone knows specifically for it - but even in general network programming - how does one sync up the server and client and ensure that they are not both trying to send at the same time, and there are no lockups (race conditions).

Is IO::Select and it's methods can_read() and can_write() enough of a check? I keep wondering - especially since the other side might try to write in the time our first write packet reaches the remote side so it's can_write() still returns yes you can write ...

OTOH as I understand in most (all?) protocols it's actually only one side that can initiate the write (if only one socket is used for communication) - either send something or ask "do you have anything new for me?" and then wait for the other side to respond - am I on the right track?

I also see that operations in UCP that are not response (ACK, NACK) contain a field called MMS (more messages to send) that I guess means - here you have this, but I keep the write permissions after you send me back ACK/NACK?

PS. All I need is a way to connect to server (UCP SMSC), login, send a message (a lot of them actually), receive the delivery notification (for all the messages) and perhaps do a ping (alert operation 31) as a "keep alive". But in lack of existing UCP SMSC software - I need to first write a dummy one - to be used for testing.

[zentara]

See the perl network examples at Prof Golden's Perl Client server basics. Of course, it is basic Perl, but modules like IO::Socket and IO::Select make things easier. As far as writing and receiving simultaneously, there are 3 solutions: use IO::Select, fork, or use threads. Generally select is used when the messages are short, because the server will only handle one client at a time. If big files are transferred, you usually using a forking design.

It's a big topic, and you can search google and groups.google.com for "perl server client", "perl server IO::Select", "perl multi-echo chat", etc. There are many variations on server client setups. In general, for a client, you want a forking client. When it connects, it immediately forks off, one fork is solely for receiving, and 1 fork for sending. See Simple bi-directional forking commandline client for a basic client that should work with almost any server, like a telnet client.

[techcode]

Yeah but I'm limited to only one socket due to EMI/UCP specification that dates back to paging systems (though extended for SMS's).

Anyway - yes forking method (IO::Socket::INET) is already used for the other protocol (SMPP) server - I just thought that module itself (Net::SMPP) is taking care of that synchronization - when in reality (since we figured that both sides can write at the same time) it is doing exactly the same as I need to do for UCP - each operation/message/reply sent to one another has a "stamp" by which you match operation and reply. Communication is async in that you can send several messages, and then latter get responses for all of those - that they are accepted/rejected.

Now knowing that both sides can write to the socket at the same time - everything makes perfect sense.

[afresh1]

Most sockets are bi-directional, so yes both ends should be able to write to a socket at the same time. That data goes into buffers that get cleaned out by reading from the socket.